[Bug]: Bundled `opencode serve` holds the shared OpenCode SQLite database — concurrent `opencode run` CLI invocations hang forever

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Install the OpenCode CLI and let it build up a normal history, so ~/.local/share/opencode/opencode.db is large (~8 GB here).
2. Launch the T3 Code desktop app with the OpenCode provider configured. The backend starts its bundled service:
   opencode serve --hostname=127.0.0.1 --port=52160
3. Leave T3 Code open, and from a separate terminal run the OpenCode CLI directly a few times:
   opencode run --pure -m <model> "hi"

Expected behavior

The CLI run either completes, or fails quickly with a clear lock/contention error.

T3 Code's bundled service should not make the user's own OpenCode CLI unusable while the app is open. Opening the shared database with a busy timeout, or in a shared-access mode, would let a concurrent CLI writer wait briefly instead of blocking forever.

Actual behavior

While T3 Code is open, concurrent opencode run invocations hang indefinitely. There is no timeout and no error — the process just never returns.

The hang happens before any network call is made:

• the process is blocked with open file descriptors on ~/.local/share/opencode/opencode.db
• 0% CPU, so it is waiting on a lock rather than doing work
• no TCP socket is ever opened to the model provider
• the machine is otherwise idle
• no lock timeout fires, and no database is locked error is ever printed

Roughly one call in several slips through and completes in about 5 seconds. The rest hang until killed manually.

Closing T3 Code (and with it the bundled opencode serve) makes the same CLI commands work normally again.

This looks related to #5099 and #6097, but it is a different database. Those cover T3's own ~/.t3/userdata/state.sqlite. This one is the OpenCode CLI's shared database at ~/.local/share/opencode/opencode.db, which the bundled service and the user's own CLI both open.

Impact

Major. While T3 Code is open, the OpenCode CLI cannot be used at all on the same machine. Because the failure is a silent indefinite hang rather than an error, scripted or headless CLI usage stalls with no signal, and the cause is not obvious from the CLI side.

Version or commit

T3 Code (Alpha) 0.0.36

Environment

• macOS 26.6.2 (Darwin 25.6.0), Apple Silicon
• OpenCode CLI 1.18.25 (also observed on 1.18.18)
• Shared OpenCode database ~/.local/share/opencode/opencode.db, about 8 GB
• Bundled service: opencode serve --hostname=127.0.0.1 --port=52160

Logs or stack traces

No output at all — that is the problem. The hung opencode run prints nothing and never exits.

Observable state while hung:

• open file descriptors on ~/.local/share/opencode/opencode.db (and its WAL/SHM files)
• 0% CPU
• no established TCP connection

Workaround

Quit T3 Code before using the OpenCode CLI directly, or point the CLI at a separate OpenCode data directory.

Start in apps/server by tracing how the bundled opencode serve process opens ~/.local/share/opencode/opencode.db and how it configures SQLite access. Reproduce with the bundled service running, then run concurrent opencode run --pure commands. Done means CLI writers wait briefly or fail with a clear lock error instead of hanging indefinitely.