`opencode run --session <id> --dir <different-dir>` hangs indefinitely after the turn completes

Version: 1.17.20 (installed via opencode-ai npm package)
Platform: macOS (darwin)

Summary

Resuming a session with --session <id> while passing a --dir that is
different from the directory the session originally started in causes
the process to hang indefinitely after the actual model turn has already
completed. The same request against the same directory the session
started in returns correctly in about a second.

Reproduction

# 1. Start a session in dirA
mkdir -p dirA dirB
opencode run --model <provider>/<model> --dir "$PWD/dirA" --auto --format json \
  "Remember this nonce: XYZZY-77. Reply with exactly one word: NOTED." > call1.jsonl
SID=$(python3 -c "import json;print(json.load(open('call1.jsonl'))['sessionID'])")

# 2. Resume that session, but with --dir pointed at dirB instead
opencode run --model <provider>/<model> --dir "$PWD/dirB" --session "$SID" --auto --format json \
  "Run pwd." > call2.jsonl
# hangs here — never returns, no output written to call2.jsonl

Resuming with --dir "$PWD/dirA" (matching the session's original
directory) instead of dirB returns correctly in ~1 second.

What I observed with --print-logs --log-level DEBUG

The debug log shows OpenCode bootstrapping two directory-scoped
instances instead of one — the --dir passed on the command line, and a
second, unrequested one for the directory the session actually started in:

message="creating instance" directory=.../dirB
message=bootstrapping         directory=.../dirB
...
message="creating instance" directory=.../dirA
message=bootstrapping         directory=.../dirA

The conversational turn itself completes normally — stream starts, and
"exiting loop" logs a few seconds later, matching the response time seen
on a same-directory resume. The hang is entirely after that point: no
further log lines appear, and the process sits at near-zero CPU
indefinitely (observed 15+ minutes in one run) until killed. This looks
like a shutdown/cleanup hang — possibly tied to tearing down the second
instance's filesystem watcher ("watcher backend" ... backend=fs-events)
— rather than anything stuck in the model or tool call path.

Expected behavior

Either: resuming with a different --dir should be rejected with a clear
error (if that combination isn't meant to be supported), or it should
complete without hanging (if switching directories on resume is intended
to work).

Why this matters

I ran into this while evaluating whether OpenCode's session resume is safe
to use for automated, unattended workflows that always invoke from a
per-task working directory. A silent hang (vs. a clean error) is the worst
outcome for that use case — I have no way to distinguish "still working" from
"stuck" without a timeout, and no clear signal to fall back on.

Happy to share the full debug log / provide more repro detail if useful.