opencode run --continue injects the prompt into a session actively in use by another running opencode instance

Summary

opencode run --continue (-c) selects the most recently updated session with no liveness check. When a second opencode instance is actively using a session, that session wins the recency race and the CLI prompt is silently injected into the foreign conversation — re-sending that session's full context (mostly cache hits, but a large request and a fresh tail).

Reproduction

1. Instance A: keep a session actively running in opencode (TUI/server).
2. Instance B: opencode run --continue "some message" from the same project directory.
3. The message lands in instance A's session, not the session you intended to continue.

In testing this happened repeatedly: three separate opencode run --continue "reply with exactly: two" runs all injected the message into the same foreign session (belonging to a concurrently-running instance), while the intended tiny test session was never continued — it still contains only its first turn.

Evidence (shared SQLite storage + source)

• The intended session contains exactly one user message and one assistant reply — --continue never touched it.
• The injected messages ("reply with exactly: two"/"three") appear in the foreign session at three distinct test times; its assistant even replied "two" to one of them.
• Token accounting shows the consequence: a ~166K-token request (input: 33,887 fresh, cache read: 132,480) — the foreign session's full context re-sent, fresh tail = the injected message.
• Source confirms the mechanism: packages/opencode/src/cli/cmd/run.ts — --continue takes the first non-child session from session.list(), ordered by desc(time_updated). No in-use check exists; sessions are just shared DB rows.

Impact

1. Data integrity: your prompt is injected into a conversation you're not looking at; the other instance's assistant responds to it.
2. Cost: full context of the foreign session re-sent on every such continue.
3. Silent: output looks like a normal continue; nothing indicates which session was actually continued.

Related

• #41562 (open, same root cause, directory trigger)
• #26099 / #25963 / #18890 / #28972 (closed, not_planned)
• #20552 (closed, not_planned)
• #36893 (open)
• #41003 (open)
• PR #42223 (open — fixes only the directory case; this scenario still reproduces)

Suggested fixes

1. Skip sessions with in-flight activity when selecting the --continue target.
2. Print the session ID/title being continued (or warn when it's actively in use elsewhere).
3. Require --session when multiple candidate sessions exist.

Environment: opencode 1.18.18, Linux, shared storage ~/.local/share/opencode/opencode.db