opencode mcp debug leaves a lock behind on exit, delaying the next session by ~60s

[SEFE-4js]

Running opencode mcp debug "<remote-oauth-mcp>" against a remote OAuth MCP server that has stored tokens leaves a lock directory under ~/.local/state/opencode/locks/. It is not removed when the command exits, and while it remains, the next process that reads mcp-auth.json is delayed by about 60 seconds. This includes starting a new session against that server, which blocks for roughly 60 seconds while connecting.

Starting from an empty ~/.local/state/opencode/locks/ and a remote OAuth MCP server with valid stored tokens:

opencode mcp debug "<remote-oauth-mcp>"   # ~2s; succeeds, but leaves a <hash>.lock directory under locks/
# then start a session that uses that server (for example `opencode`, or an ACP client via `opencode acp`)
# the session blocks for ~60s while connecting, then continues

The command also affects itself when run consecutively:

opencode mcp debug "<remote-oauth-mcp>"   # first run: ~2s
opencode mcp debug "<remote-oauth-mcp>"   # second run: ~60s, blocks for the full duration, then proceeds

In each case a <hash>.lock directory is present after the first run that was not there beforehand. The next read waits until the lock is treated as stale (about 60 seconds) before proceeding; removing the directory in advance avoids the delay. The leftover appears to be the lock guarding mcp-auth.json (the locking added in #29852); it is not released when mcp debug exits, so a session that reads the same file afterwards waits on it.

Expected behaviour: once mcp debug exits, the lock is released and subsequent reads and connections are not delayed.

Environment:

• opencode 1.18.4
• reproduced on macOS, Linux and Windows (same ~/.local/state and ~/.local/share layout on each)
• remote OAuth MCP server with stored tokens in ~/.local/share/opencode/mcp-auth.json

[g0rdonL]

I can reproduce both the leftover lock and the ~60s block on macOS arm64 with opencode 1.18.4, but the lock that leaks in my repro is not the mcp-auth.json lock — it's the models.dev cache lock, and the leak mechanism is more general than mcp debug.

Which lock leaks

After opencode mcp debug <name> exits, the leftover directory here is ~/.local/state/opencode/locks/6251b8120957462d86ba54bc0adf30b7be66db18.lock. That hash is sha1("models-dev:" + <home>/.cache/opencode/models.json) — the lockKey built at packages/core/src/models-dev.ts:160, hashed via Hash.fast (sha1) in Flock.acquire (packages/core/src/util/flock.ts:321). The mcp-auth key hashes to a different value (abdb1404... for my home dir), and that lock does not appear in my runs.

Leak mechanism (deterministic here)

The ModelsDev layer forks a background refresh on startup (models-dev.ts:249-252). Whenever ~/.cache/opencode/models.json is older than the 5-minute TTL, refresh() acquires the flock and starts the network fetch of models.dev/api.json. A short CLI command finishes first and hits the unconditional process.exit() in the finally block of packages/opencode/src/index.ts:141, which kills the process before the Effect release finalizer runs — lock dir left behind with no live owner, and models.json is not updated. Repro:

rm -rf ~/.local/state/opencode/locks
touch -t <10-minutes-ago> ~/.cache/opencode/models.json
opencode mcp debug <any-remote>    # ~0.4s, exit 0
ls ~/.local/state/opencode/locks   # 6251b812....lock left behind, models.json mtime unchanged

This leaks on every short-lived run whose models cache is stale. No OAuth involved — my test config was a plain {"type":"remote","url":"https://example.com/mcp","oauth":{}} with no stored tokens.

The ~60s block

A leaked lock's heartbeat stops when the process dies, so the next process that has to acquire the same key waits until it's considered stale (STALE_MS = 60_000 in both flock.ts and effect-flock.ts). Measured: with a fresh lock dir planted on the mcp-auth key, opencode mcp debug takes 61.7s wall vs 0.44s baseline. So the reported 60s delay is consistent with this same mechanism leaking the mcp-auth lock in the OAuth path — any fiber holding a flock at the moment process.exit() fires leaks it identically.

Given that, the fix probably belongs at the exit path (release held locks before the hard process.exit()), or short-lived commands shouldn't fork the models refresh — rather than anything specific to mcp debug.