You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
opencode run fails with Session not found when OPENCODE_SERVER_PASSWORD is set #24204
Run the same command after unsetting the server auth env vars:
```bash
env -u OPENCODE_SERVER_PASSWORD -u OPENCODE_SERVER_USERNAME \
opencode run "Reply with exactly OK."
```
Observe that `opencode run` proceeds normally.
Expected: `opencode run` should work when `OPENCODE_SERVER_PASSWORD` is set, or at least authenticate its own in-process server requests consistently with the server auth config.
Actual: the in-process server rejects the SDK client's session creation request, and the CLI reports `Session not found`.
opencode run fails with 'Session not found' (1.1.16) #8502 has the same user-visible opencode run / Session not found symptom, but it is a broader older report. This issue is specifically the OPENCODE_SERVER_PASSWORD in-process server path: plain opencode run starts its own in-process server, that server applies auth from OPENCODE_SERVER_PASSWORD, and the in-process SDK client does not send matching Basic Auth headers.
This also happens naturally from an OpenCode Desktop-inherited process environment. Desktop starts its local sidecar with an ephemeral OPENCODE_SERVER_PASSWORD, and child shell/CLI processes can inherit that variable. A local non---attachopencode run then fails with Error: Session not found.
Minimal repro still works with a dummy password on 1.14.28:
OPENCODE_SERVER_PASSWORD=dummy-password-for-repro opencode run -m openai/gpt-5.5-fast --variant xhigh "Reply exactly: OK"
# Error: Session not found
env -u OPENCODE_SERVER_PASSWORD opencode run -m openai/gpt-5.5-fast --variant xhigh "Reply exactly: OK"
# OK
No real secret values involved; this is just confirming the issue persists on 1.14.28 and documenting the Desktop inheritance path.
This is actually an issue more generally for running opencode with --mdns or --hostname. I've flagged separately in #29847 29847 before I saw this issue.
Activity
github-actions commentedon Apr 24, 2026
This issue might be a duplicate of existing issues. Please check:
opencode runfails withSession not found(same command, same error — different root cause suspected but worth verifying)OPENCODE_SERVER_PASSWORDis set (same env var, same auth failure pattern, different code path)If your issue is distinct from the above, please add a note clarifying how it differs.
rmk40 commentedon Apr 24, 2026
Clarifying the duplicate suggestions:
opencode run/Session not foundsymptom, but it is a broader older report. This issue is specifically theOPENCODE_SERVER_PASSWORDin-process server path: plainopencode runstarts its own in-process server, that server applies auth fromOPENCODE_SERVER_PASSWORD, and the in-process SDK client does not send matching Basic Auth headers.opencode run.The linked PR targets only the plain
opencode runin-process SDK client path.rayborg commentedon Apr 28, 2026
Additional confirmation on current versions:
1.14.281.14.2826.4, arm64This also happens naturally from an OpenCode Desktop-inherited process environment. Desktop starts its local sidecar with an ephemeral
OPENCODE_SERVER_PASSWORD, and child shell/CLI processes can inherit that variable. A local non---attachopencode runthen fails withError: Session not found.Minimal repro still works with a dummy password on
1.14.28:No real secret values involved; this is just confirming the issue persists on
1.14.28and documenting the Desktop inheritance path.hades200082 commentedon May 27, 2026
Same issue here. Prevents open-ralph-wiggum from working.
Th0rgal/open-ralph-wiggum#84
rmk40 commentedon May 27, 2026
There does not seem to be much appetite for outside PRs, so I've stopped pursuing trying to land this and other fixes.
blairhudson commentedon May 29, 2026
This is actually an issue more generally for running
opencodewith--mdnsor--hostname. I've flagged separately in #29847 29847 before I saw this issue.OpeOginni commentedon May 29, 2026
Worked on the other Issue, got a PR for this issue as well