Bug: opencode run fails silently when desktop app env vars are set (OPENCODE_SERVER_PASSWORD)

Summary

When the OpenCode desktop app is running, it sets OPENCODE_SERVER_PASSWORD, OPENCODE_SERVER_USERNAME, and OPENCODE_CLIENT in the shell environment. If a user then runs opencode run from a terminal spawned within that environment (common when using the integrated terminal in the desktop app, or when the desktop app is open and env is inherited), the CLI fails silently.

Root cause

The CLI's internal in-process server reads OPENCODE_SERVER_PASSWORD and enforces Basic Auth on all requests. However, opencode run mode's internal HTTP client sends no Authorization header — it never did, because historically the password was only set when the desktop app was active. After the desktop app started setting these env vars, run mode broke for any user with the app open.

Reproduction

Open the OpenCode desktop app
Open a terminal (or any shell that inherits the app's environment)
Run: opencode run "hello" -m anthropic/claude-sonnet-4-6 --format json
Observe: the session starts but produces no output (auth rejected silently) — or the process exits immediately with no error message

Verification

Check whether these vars are set:

echo $OPENCODE_SERVER_PASSWORD
echo $OPENCODE_SERVER_USERNAME
echo $OPENCODE_CLIENT

If any are non-empty, run mode is affected.

Workaround

Unset the vars before calling opencode run:

env -u OPENCODE_SERVER_PASSWORD -u OPENCODE_SERVER_USERNAME -u OPENCODE_CLIENT \
  opencode run "your message" --dir /path/to/project

Expected behavior

opencode run should work regardless of whether the desktop app environment vars are present. Either:

run mode should include the auth header if OPENCODE_SERVER_PASSWORD is set, or
the CLI should unset/ignore these vars before starting its own internal server in run mode

Environment

opencode v1.2.10
macOS (darwin arm64)
Reproduced consistently when desktop app is running

This issue might be a duplicate of existing issues. Please check:

[BUG] Plugin client missing Authorization header when OPENCODE_SERVER_PASSWORD is set #9706: Plugin client missing Authorization header when OPENCODE_SERVER_PASSWORD is set — same root cause (internal client not forwarding auth header when password env var is present)
OPENCODE_SERVER_PASSWORD in env prevents user from working in TUI #8173: OPENCODE_SERVER_PASSWORD in env prevents user from working in TUI — same env var causing auth failures in a different mode

Correction / more precise diagnosis:

After further testing, the failure mode is more nuanced than originally described.

Corrected root cause

When OPENCODE_CLIENT=desktop is set, opencode run routes through the running desktop app's server instead of spawning its own in-process server. Auth works fine (the password is in env). But the desktop server only knows about directories that have active sessions open in the desktop UI.

Result:

# Works — current dir IS open in desktop app:
opencode run "hello" -m anthropic/claude-sonnet-4-6 --format json
# → valid JSON session

# Fails — /tmp/mydir has NO active desktop session:
opencode run "hello" --dir /tmp/mydir -m anthropic/claude-sonnet-4-6 --format json
# → Error: Session not found

What this means

opencode run with --dir pointing to any directory not currently open in the desktop app will fail with Error: Session not found if the desktop app is running.

This affects:

All scripted/CI usage of opencode run --dir when the desktop app is also open
Plugin test harnesses
Any automation that targets arbitrary directories

Workaround (confirmed)

env -u OPENCODE_SERVER_PASSWORD -u OPENCODE_SERVER_USERNAME -u OPENCODE_CLIENT \
  opencode run "hello" --dir /tmp/mydir -m anthropic/claude-sonnet-4-6

Expected fix

opencode run should spawn its own isolated in-process server regardless of whether the desktop app is running — the same way it behaves when the desktop app env vars are absent. The --dir flag semantics in run mode imply a self-contained session, not a lookup against the desktop server.

Flagged as potential duplicate of #9706 and #8173 by the bot — worth noting the distinction:

OPENCODE_SERVER_PASSWORD in env prevents user from working in TUI #8173 covers TUI mode broken by the env var — different mode, different symptom
[BUG] Plugin client missing Authorization header when OPENCODE_SERVER_PASSWORD is set #9706 covers missing auth header in plugin client — matches our original diagnosis but our corrected finding is different: the failure is OPENCODE_CLIENT=desktop causing opencode run to route to the desktop server's session pool, returning Error: Session not found for any --dir not currently open in the desktop UI. This is a session routing issue, not an auth header issue.

If maintainers consider this covered by #9706 or #8173, happy to close. If the routing-to-desktop-server behaviour is a distinct code path, the fix location would be different.

Correcting the reproduction example — the directory must exist first:

mkdir -p /tmp/mydir

# Fails with desktop app running (OPENCODE_CLIENT=desktop set):
opencode run "hello" --dir /tmp/mydir -m anthropic/claude-sonnet-4-6 --format json
# Error: Session not found

# Works after unsetting the vars:
env -u OPENCODE_SERVER_PASSWORD -u OPENCODE_SERVER_USERNAME -u OPENCODE_CLIENT \
  opencode run "hello" --dir /tmp/mydir -m anthropic/claude-sonnet-4-6 --format json
# → valid JSON session

Closing — unable to reproduce from a regular user terminal. The failure only occurred when running opencode run via a subprocess spawned from within the OpenCode process itself (which inherits OPENCODE_CLIENT=desktop). Not a real user-facing bug. Apologies for the noise.

I can still reproduce this on OpenCode 1.14.19, and I think it is user-facing.

In the OpenCode app Terminal, this fails:

opencode run --pure -m "cpa/gpt-5.4" "Reply with exactly OK."

Result:

Error: Session not found

The exact same command works in a regular macOS Terminal and returns OK.

It also works in the OpenCode app Terminal after unsetting the inherited env:

env -u OPENCODE \
    -u AGENT \
    -u OPENCODE_CLIENT \
    -u OPENCODE_RUN_ID \
    -u OPENCODE_PROCESS_ROLE \
    -u OPENCODE_PID \
    -u OPENCODE_SERVER_USERNAME \
    -u OPENCODE_SERVER_PASSWORD \
    opencode run --pure -m "cpa/gpt-5.4" "Reply with exactly OK."

So this does not seem limited to an internal subprocess-only case. It is reproducible from the Desktop app's own Terminal UI. If that changes the conclusion here, would you consider reopening this? If you prefer to track it under #8502 , I am happy to move the repro there.

I can still reproduce the OPENCODE_SERVER_PASSWORD variant on OpenCode 1.14.24.

From a shell where OPENCODE_SERVER_PASSWORD is set:

opencode run --pure "Reply with exactly OK."

Actual:

Error: Session not found

The same command succeeds after unsetting the inherited server env vars:

env -u OPENCODE_SERVER_PASSWORD -u OPENCODE_SERVER_USERNAME -u OPENCODE_CLIENT \
  opencode run --pure "Reply with exactly OK."

This matches the repro in this issue. Could this be reopened?

Small correction: my repro does not require --pure; that was only included to rule out local config/plugins.

This also reproduces with plain run:

opencode run "Reply with exactly OK."

Actual:

Error: Session not found

I had the same issue, but was able to fix it once i aligned the opencode version used in the desktop app with the one used in the cli by upgrading the cli using opencode upgrade. IDK if this helps.

Navigation Menu

Repository navigation

Bug: opencode run fails silently when desktop app env vars are set (OPENCODE_SERVER_PASSWORD) #14532

Summary

Root cause

Reproduction

Verification

Workaround

Expected behavior

Environment

Corrected root cause

What this means

Workaround (confirmed)

Expected fix

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Bug: opencode run fails silently when desktop app env vars are set (OPENCODE_SERVER_PASSWORD) #14532

Description

Summary

Root cause

Reproduction

Verification

Workaround

Expected behavior

Environment

Activity

github-actions commented on Feb 21, 2026

clarkbalan commented on Feb 21, 2026

Corrected root cause

What this means

Workaround (confirmed)

Expected fix

clarkbalan commented on Feb 21, 2026

clarkbalan commented on Feb 21, 2026

clarkbalan commented on Feb 21, 2026

233Official commented on Apr 21, 2026

rmk40 commented on Apr 24, 2026

rmk40 commented on Apr 24, 2026

rubenschulze commented on Jun 9, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions