shell: every spawn fails with ERROR_PATH_NOT_FOUND on Windows (path specified) until shell is pinned to an absolute path #55733

Activity

1. opencode-agent commented on Oct 15, 2026

   

   opencode-agentBot

   on Oct 15, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed report. I couldn't try to reproduce this, because it only happens on Windows (it showed up in the desktop app's background service after a few days) and our test environment is Linux, so it will need a maintainer with a Windows machine.

   Some notes from reading the code, for whoever picks it up. None of this is confirmed:

   • When no shell is configured, the resolved shell is cached for the whole server process and never refreshed. A configured shell skips that cache, which would explain why your workaround works after a hot-reload without a restart.
   • If no shell is found, the code silently falls back to cmd.exe (via COMSPEC). The error text The system cannot find the path specified. looks like cmd.exe's own message rather than a failure to start the process. So cmd.exe may have been picked and then hit a path that didn't exist.

   If it happens again before you set the workaround, any log lines from that session about the shell or the instance would help.

   Related:

   • Windows: pwsh installed as a Store app-execution alias is not resolved, so the shell falls back to Windows PowerShell 5.1 #55255: same silent fallback in shell resolution, for Store-installed pwsh
   • cli: no way to refresh environment variables without restarting #48919: environment changes aren't picked up without restarting the service

   Until then, setting "shell" to an absolute path in your global config works around it, as you found.
2. hrabbach commented on Oct 15, 2026

   

   hrabbach

   on Oct 15, 2026

   Last edited by hrabbach

   Author

   More actions

   Correction to my previous comment — please disregard its speculation.

   Corrected facts (verified with the reporter):

   • The background service had been running for only ~1 hour when the failure appeared. Nothing on this machine's shells changed in that window — both pwsh 7.6.6 (C:\Program Files\PowerShell\7\pwsh.exe) and Git bash.exe exist and execute fine. So the "cached path stopped existing / Git moved" narrative was unfounded, and the earlier shell activity seen in the log belonged to a previous service run, not this one.
   • What is verified: with no shell configured, every shell tool call fails with The system cannot find the path specified. + exit 1 (including echo hello, with or without a valid workdir). Toggling "shell": "C:\\Program Files\\PowerShell\\7\\pwsh.exe" in global config off/on via config hot-reload toggles the failure in the same running process — broken without the key, working with it.
   • So the accurate statement is: on this machine, startup shell resolution selects an executable that does not work (spawn via the cmd wrapper fails), and that choice is cached for the process lifetime; an absolute configured shell bypasses the cache entirely. Both plausible pwsh/bash candidates exist on disk, so whatever the resolver picked, it wasn't a usable one — consistent with the silent-fallback weakness in shell/select.ts (cf. Windows: pwsh installed as a Store app-execution alias is not resolved, so the shell falls back to Windows PowerShell 5.1 #55255), but the exact resolved value is unconfirmed.

   Next step if useful: run a fresh opencode --standalone (or restarted service) with OPENCODE_LOG_LEVEL=DEBUG on this machine to capture exactly what the resolver selects at startup. Happy to do that on request.

   And to restate the earlier point with the corrected timeline: since the bad resolution is cached at process start, the practical impact is that a machine where resolution goes wrong gets a completely broken shell tool — for every project, every command — with an error message that names no path and hints at no config remedy.
3. hrabbach commented on Oct 15, 2026

   

   hrabbach

   on Oct 15, 2026

   Author

   More actions

   Update after a debug capture session — the plot thickens in a useful way.

   What we did: killed the affected service (opencode.exe serve --service, started ~1 h before the failure) and started a fresh one with OPENCODE_LOG_LEVEL=DEBUG / --print-logs, with no shell configured (the config workaround removed).

   Result: on the fresh service, the shell tool works. The debug log shows serve-mode resolution picking the exact expected binary:

   message="spawning process" command="C:\Program Files\PowerShell\7\pwsh.EXE" args="[\"-NoLogo\",\"-NoProfile\",\"-NonInteractive\",\"-Command\",...]" cwd="..." role=server
   

   Earlier, a fresh opencode run --standalone (no shell configured, env inherited from the service) resolved the same pwsh.EXE and worked as well.

   Conclusion so far:

   • Shell resolution logic works correctly on this machine in both run and serve --service modes, in the service's own environment.
   • The failure was bound to the previous service process's in-memory cached resolution, which had become invalid at some point during that process's ~1 h lifetime and poisoned every subsequent spawn (config hot-reload toggle proved the cache is read per spawn and bypassed by a configured shell).
   • The trigger that poisons the cache is still unknown — it is not "path existed at startup and was later deleted" (nothing changed on the machine's shells), and it does not reproduce on a fresh service so far.

   Practical notes for whoever picks this up:

   • Impact when it hits: every shell tool call in every project fails with a raw OS error (The system cannot find the path specified., exit 1) for the life of the service process — severe but recoverable.
   • Recovery that worked instantly without killing the session: set "shell" to an absolute path in global config (hot-reload bypasses the cache). A service restart also clears it.
   • Suggested hardening (restated with the new evidence): validate the cached shell executable exists (and actually spawned) before use; on spawn failure, re-resolve once and warn with the resolved path instead of failing every call silently. The error signature (cmd.exe's own "path not found" text on every command, even echo hello) suggests the cached value was a path that did not exist at spawn time.

   Reporter's config is back to no shell key and shell is working; will update if the failure reappears and a capture of the poisoned state becomes possible.