web backend Gateway config

[snac21]

Gateway 自启动配置缺失与路径解析问题报告

问题描述

在使用 picoclaw-launcher (Web Backend) 控制面板通过调用 /api/gateway/start 接口启动 picoclaw 网关服务时，遇到以下两类报错：

1. 二进制文件路径未找到 executable file not found in $PATH:
   • HTTP Status 500
   • Failed to auto-start gateway: failed to start gateway: exec: "picoclaw": executable file not found in $PATH
2. 配置文件缺省导致启动奔溃:
   • 终端日志显示 gateway 进程启动后立即退出 (Exit Code 1)
   • Error: error creating provider: model "" not found in model_list: model "" not found in model_list or providers

此外，页面调用 /api/gateway/status 等待时会出现 Gateway 状态异常 (Status: "stopped", Start_Allowed: true)。

问题根本原因

1. 相对路径兼容性缺失：在 web/backend/api/gateway.go 的 findPicoclawBinary() 中，仅扫描了启动器所在目录和系统环境变量的 $PATH。但是在本地 Makefile 测试环境中，picoclaw 编译于 build/picoclaw 路径下，而 picoclaw-launcher 编译与执行在 web/backend/dist 中，这导致跨目录启动时无法定位到网关程序二进制文件。
2. 配置隔离：picoclaw-launcher 支持通过命令行参数接收配置文件路径 (例如: make run CONFIG_PATH=/path/to/config.json)。但在 api/gateway.go 的启动逻辑中，exec.Command(execPath, "gateway") 并没有将该配置路径转发给启动的网关。
   • picoclaw gateway 存在默认的配置读取逻辑 ~/.picoclaw/config.json。
   • 当 ~/.picoclaw/config.json 不存在或者其中并未有效配置模型提供商(Provider)时，Gateway 瞬间抛出 Panic 退出，即 Exit status 1。这就解释了为什么 Launcher 显示为 Stopped 但实际上后端有触发过 Start().

解决方案与修复代码

1. 完善二进制文件路径探测 findPicoclawBinary()

在搜索策略中添加相对当前执行目录和工作目录的前置路径检查，例如：

// 匹配 web/backend 结构与全局 build 输出
for _, rel := range []string{"..", "../..", "../../.."} {
    candidate := filepath.Join(dir, rel, "build", binaryName)
    if info, err := os.Stat(candidate); err == nil && !info.IsDir() {
        return candidate
    }
}

2. 将配置路径显式传递给 Gateway 进程

修改 startGatewayLocked() 中 exec.Command 的参数列表：

// 通过 --config 显示指定配置给网关
cmd := exec.Command(execPath, "gateway", "--config", h.configPath)

测试结果

修复后，通过面板控制网关启动，网关不再受限于未全局安装的限制，且将成功读入面板指定的 config.json 并进入正常 Running 状态，与状态 API 相挂钩同步无误。

[nikolasdehor]

Good analysis. Looking at the web backend code:

Issue 1 - Binary path: In web/backend/api/gateway.go, findPicoclawBinary() searches the launcher's directory and $PATH, but when running from web/backend/dist/, the build output at build/picoclaw is in a parent directory. The fix you proposed (searching relative paths like ../../build/) is reasonable, though I'd also suggest checking os.Getenv("PICOCLAW_BINARY") first as an explicit override, then falling back to the relative path search:

if p := os.Getenv("PICOCLAW_BINARY"); p != "" {
    if info, _ := os.Stat(p); info != nil && !info.IsDir() {
        return p
    }
}

Issue 2 - Config path forwarding: The startGatewayLocked() call to exec.Command(execPath, "gateway") missing --config is a clear bug. The launcher already knows the config path (from h.configPath or the --config CLI flag) but doesn't pass it downstream.

Crash on empty model: The gateway panicking when ~/.picoclaw/config.json has no model configured is a separate robustness issue. pkg/providers/factory.go should return a clear error message rather than panic — "model \"\" not found" is technically an error return, but the gateway should handle this gracefully instead of exit code 1.

Would you like to submit a PR with these fixes? The changes are well-scoped and testable.