opencode run resolves session directory from $PWD instead of process cwd (breaks headless spawn) #47080

Description

When opencode run is spawned as a subprocess with a working directory set (Node spawnSync/spawn cwd, Python subprocess cwd, posix_spawn, …) and inherits a stale PWD — which is the normal case, since spawn APIs set the process cwd but do not rewrite the environment variable — the CLI bootstraps the correct directory once, then creates a second instance resolved from env.PWD and registers the session there. Project-local .opencode/ config (agents, commands) then resolves against the wrong directory.

In our case (headless CI-style runner): --command/--agent names that exist in the cwd's .opencode/ were missing in the $PWD instance, and SessionPrompt.command threw, surfacing as a 500 {"name":"UnknownError","message":"Unexpected server error. Check server logs for details."} ~200ms after session creation, with no corresponding entry in the opencode log.

From the 1.18.27 binary the resolution is literally resolve(process.env.PWD ?? process.cwd()). --dir is unaffected because it goes through process.chdir().

OpenCode version

1.18.27

Steps to reproduce

mkdir -p /tmp/real && cd /tmp/real && git init -q
env PWD=/tmp opencode run --print-logs "say ok"

Expected: the session registers in /tmp/real.

Actual: the logs show a second creating instance at /tmp and the session is created there (project global), losing the real directory's .opencode config. The same run with a correct PWD, or with --dir /tmp/real, registers /tmp/real.

Workaround: set PWD in the child environment, or pass --dir.

Secondary point

A --command/--agent that does not resolve in the effective directory should fail with a clear 4xx ("unknown command: …"), not a generic 500 — the opaque UnknownError plus the absent log entry made this much harder to diagnose than it needed to be.

Related

#41841 and #46276 report the same "two directory-scoped instances" signature via --session + a mismatched --dir; the $PWD-over-cwd resolution above looks like the underlying cause.

Operating System

macOS (Apple Silicon)

Terminal

n/a — headless subprocess