bug(acp): providers installed after the daemon started stay unresolved on Windows, and a handshake exit reports as a 120s timeout #8303

What's broken

Two related failures on Windows, both affecting ACP providers (Kimi Code CLI, MiniMax Code) that were installed after the Paseo daemon started:

1. Provider shows as "not installed" / unavailable. The daemon's supervisor process holds the PATH it inherited when it was launched. On Windows, a newly installed CLI updates the registry Path value but the running daemon never sees it, so the launcher binary is not resolvable even though it is on PATH in a fresh shell.

2. Provider shows "error" with a 120s timeout. When the configured command is a broken npx invocation, the child process exits during the ACP handshake. The SDK's initialize request never rejects in that case, so the provider refresh waits out its full 120-second deadline and reports:

   Timed out refreshing MiniMax Code after 120000ms; pending: initialize
   

   The child's actual stderr is never surfaced, so the message gives no hint of the real cause.

Steps to reproduce

1. Start Paseo on Windows.
2. Install an ACP agent CLI afterwards (e.g. Kimi Code CLI or MiniMax Code) — the installer adds its directory to the registry Path value.
3. Add the CLI as a custom provider in Paseo.
4. Observe the provider as unavailable / "not installed", and its refresh failing with the 120s timeout above.

The provider stays broken until the whole daemon tree is restarted, and restarting only the worker does not help, because the supervisor passes its own stale PATH down to every worker it spawns.

Where did this happen

Daemon

Paseo version

0.14.0

OS version

Windows 11

Agent provider

Custom provider

Provider configuration

{
  "agents": {
    "providers": {
      "kimi": {
        "extends": "acp",
        "label": "Kimi Code CLI",
        "command": ["kimi", "acp"]
      },
      "minimax-code": {
        "extends": "acp",
        "label": "MiniMax Code",
        "command": ["npx", "-y", "@minimax-ai/code@0.6.13", "acp"]
      }
    }
  }
}

Both CLIs are installed and working outside Paseo:

$ kimi --version
2.4.1

$ mcode --version
0.7.1

Both answer an ACP initialize handshake directly:

$ kimi acp   ->  {"jsonrpc":"2.0","id":1,"result":{"protocolVersion":1,...,"agentInfo":{"name":"kimi",...}}}
$ mcode acp  ->  {"jsonrpc":"2.0","id":1,"result":{"protocolVersion":1,...,"agentInfo":{"name":"minimax-code","version":"0.7.1"},...}}

The registry Path value does contain both install directories:

> [Environment]::GetEnvironmentVariable('Path','User')
C:\Users\17729\.kimi-code\bin
C:\Users\17729\.minimax-code

Logs

Raw daemon log lines from the daemon that was running before the CLIs were installed (PID 77928):

{"level":40,"time":1793366288797,"pid":77928,"hostname":"RabbitQ","daemonVersion":"0.14.0","module":"bootstrap","module":"provider-snapshot-manager","err":{"type":"Error","message":"Timed out refreshing MiniMax Code after 120000ms; pending: initialize","stack":"Error: Timed out refreshing MiniMax Code after 120000ms; pending: initialize\n    at Timeout.<anonymous> (file:///D:/Programs/Paseo/resources/app.asar/node_modules/@getpaseo/server/dist/server/server/agent/provider-refresh-deadline.js:49:24)\n    at listOnTimeout (node:internal/timers:685:17)\n    at process.processTimers (node:internal/timers:618:7)"},"provider":"minimax-code","target":{"scope":"global","force":true},"msg":"Failed to refresh provider snapshot"}
{"level":40,"time":1793366395802,"pid":77928,"hostname":"RabbitQ","daemonVersion":"0.14.0","module":"bootstrap","module":"provider-snapshot-manager","err":{"type":"Error","message":"Timed out refreshing MiniMax Code after 120000ms; pending: initialize","stack":"Error: Timed out refreshing MiniMax Code after 120000ms; pending: initialize\n    at Timeout.<anonymous> (file:///D:/Programs/Paseo/resources/app.asar/node_modules/@getpaseo/server/dist/server/server/agent/provider-refresh-deadline.js:49:24)\n    at listOnTimeout (node:internal/timers:685:17)\n    at process.processTimers (node:internal/timers:618:7)"},"provider":"minimax-code","target":{"scope":"workspace","cwd":"D:\\GitHubProjects\\paseo","force":false},"msg":"Failed to refresh provider snapshot"}

The repeated entries continue for every workspace scope until the daemon is restarted.

paseo provider diagnostic minimax-code on that same daemon, which is what surfaced the real cause:

MiniMax Code (ACP)
  Provider ID: minimax-code
  Configured command: mcode acp
  Launcher binary: mcode
  Resolved path: not found
  Version: unknown
  Version command: mcode --version
  ACP spawn: ok (21ms)
  ACP initialize: error: ACP initialize timed out after 20000ms
  ACP stderr: 'mcode' 不是内部或外部命令，也不是可运行的程序或批处理文件。
  ACP cleanup: ok (0ms)
  Models: ?  Status: Unavailable

Note that the diagnostic shows 'mcode' 不是内部或外部命令 (the child's real stderr), while the snapshot manager only ever reports the 120s timeout.

The same run for Kimi:

Kimi Code CLI (ACP)
  Provider ID: kimi
  Configured command: kimi acp
  Launcher binary: kimi
  Resolved path: not found
  Version: unknown
  Version command: kimi --version
  ACP spawn: ok (19ms)
  ACP initialize: error: ACP initialize timed out after 20000ms
  ACP stderr: 'kimi' 不是内部或外部命令，也不是可运行的程序或批处理文件。
  ACP cleanup: ok (0ms)
  Models: ?  Status: Unavailable

Screenshots or video

Not applicable — reproducible from the CLI with paseo provider diagnostic <provider> and paseo provider ls.

Relationship to existing issues

This is the ACP-provider counterpart of #6235 ("Pi diagnostic resolves npm pi.cmd on Windows, but RPC runtime launches bare pi and fails"). #6235's diagnosis matches: the runtime launches the bare default command while the diagnostic resolves a concrete path, and on Windows the spawned shell re-resolves the bare name against its own PATH/PATHEXT.

What is different here:

• bug: Pi diagnostic resolves npm pi.cmd on Windows, but RPC runtime launches bare pi and fails #6235 is about the Pi provider's RPC runtime. fix(pi): launch the resolved Pi binary instead of the bare name #6432 and fix(server): resolve Pi from the effective launch environment #6237 are open fixes for that provider. The ACP provider path has no equivalent fix — ACPAgentClient.resolveLaunchCommand() and GenericACPAgentClient.resolveLaunchCommand() resolve an absolute path through checkProviderLaunchAvailable() and then discard it, spawning the bare command instead. Every ACP provider in the catalog is affected, not just one.
• The stale-PATH-from-the-registry half is not covered by bug: Pi diagnostic resolves npm pi.cmd on Windows, but RPC runtime launches bare pi and fails #6235 or fix(pi): launch the resolved Pi binary instead of the bare name #6432: the daemon never re-reads the Windows registry Path value, so a CLI installed after the daemon started stays invisible to it. @risutrex noted the related risk in MiniMax Code from the ACP provider catalog fails with "could not determine executable to run" #6948: "npx itself must be on the daemon's PATH for the package-runner form to work at all."
• The 120s-timeout-instead-of-stderr half affects all ACP providers, including ones whose command is correct.

Additional detail

On the MiniMax Code catalog entry specifically: the catalog was corrected in #8201 (merged as 1f79efc), but that only applies when adding the provider. A config.json written by an older client still contains ["npx", "-y", "@minimax-ai/code@0.6.13", "acp"], and the persisted command is never migrated — so existing setups keep failing. This is the "Existing saved commands still need the explicit package and binary form" note in the closing comment on #6948, but the migration itself is missing.