Skip to content

tui: instances sharing the background service hang together when switching VS Code terminal tabs (macOS) #55377

New issue
New issue
Closed as not planned
Closed as not planned
tui: instances sharing the background service hang together when switching VS Code terminal tabs (macOS)#55377
Labels
triaging

Description

@shivamtiwari3
shivamtiwari3
opened on Oct 14, 2026

Summary

Running opencode in several VS Code integrated terminal tabs and switching between those tabs makes opencode stop responding. With multiple instances attached, they stall together. Claude Code in the same setup does not — it has no shared background service.

Environment

  • opencode version: 2.0.29 (channel=latest local=false)
  • OS: macOS 27.0.1 (arm64), kernel 27.0.0
  • Terminal: VS Code integrated terminal (TERM_PROGRAM=vscode, TERM=xterm-256color)
  • Shell: /bin/zsh
  • Install: managed binary, ~/.opencode/bin/opencode

Steps to reproduce

  1. Open VS Code with several integrated terminals.
  2. Run opencode in each one (same project or different projects).
  3. Switch between the terminal tabs, or switch away from VS Code and back.
  4. opencode becomes unresponsive — keystrokes are accepted but no output is rendered, or the pane appears frozen.

Expected

Each instance stays responsive when the terminal is (un)focused, as it would if it ran its own engine.

Actual

  • Every attached TUI stops responding at the same time.
  • opencode service status still prints the URL while the clients look stuck; restarting the service clears it.
  • Observed 10 concurrent opencode client processes all attached to a single opencode serve --service (PID 91857).

Diagnostics from the reporting machine

  • One shared service, many clients. ps shows a single opencode serve --service and 10 opencode clients parented by different zsh processes; some had been alive for ~2 days.
  • Bloated database. ~/.local/share/opencode/opencode.db is 360 MB with roughly 60% free pages (freelist_count 55,002 of page_count 92,226 ≈ 200 MB reclaimable by VACUUM). Table data: session_message 92 MB, part 41 MB, message 10 MB, kv 6 MB.
  • Continuous snapshot churn. ~/.local/share/opencode/log/opencode.log contains 2,366 spawning process … snapshot/… diff-files|ls-files entries, plus recurring provider.updated / model.updated events across every location.
  • Stale clients. Four long-lived clients are still on 2.0.27 (update check current=2.0.27 latest=2.0.29), i.e. several instances were never restarted after an upgrade.

Hypothesis

Because v2 routes every TUI through one background service, any per-request stall in that service (SQLite write-lock contention on the large, mostly-free database, or a busy event loop) blocks all clients at once. Switching terminal tabs does not cause the stall; it makes an already-stuck service visible. opencode --standalone runs a private server per TUI and should not show this — worth adding to triage.

Not a duplicate (as far as I can tell)

Requests

  1. Make the shared service resilient to one slow client/request: per-request timeouts and backpressure so a stalled session cannot freeze every attached TUI.
  2. Investigate SQLite write-lock contention with many concurrent clients, and reclaim/report the free-page bloat.
  3. Document (or bound) how many TUIs should share one service; consider surfacing a "service busy" state instead of a silent freeze.

Activity

  1. opencode-agent commented on Oct 14, 2026

    @opencode-agent
    opencode-agentBot
    on Oct 14, 2026 – with OpenCode Agent
    Contributor

    Thanks for the detailed diagnostics! As you say, switching tabs only reveals the freeze; it doesn't cause it. To reproduce this we need to know what the shared service is doing while the clients are stuck. Next time it happens, could you check:

    1. CPU of the opencode serve --service process during the freeze (top -pid <pid> or Activity Monitor). Is it near 100% or idle?
    2. Does the service answer? Run curl -m 5 <url from opencode service status>. Does it respond, and how fast?
    3. Log lines from around the freeze in ~/.local/share/opencode/log/opencode.log (the minute or two before and during it), especially any Event stream stalled or Background service is unresponsive lines.
    4. Does opencode --standalone avoid it under the same workflow?
    5. Does it still happen with only one or two TUIs on 2.0.29? Some of your clients were still on 2.0.27.

    A short description in your own words of what you were doing when it froze would also help.

    You can reply here or edit the issue. If you edit it, please also leave a comment saying you've updated it, so we know you're done.

    These existing issues are closely related (ordered by likelihood). Please check whether one of them already covers your problem:

  2. opencode-agent
    added
    triaging
    on Oct 14, 2026

  3. shivamtiwari3 commented on Oct 14, 2026

    @shivamtiwari3
    shivamtiwari3
    on Oct 14, 2026
    Author

    Correcting my own report after checking current dev:

    The snapshot cross-process index race I hypothesized is already handled upstream. Snapshot moved to packages/core/src/snapshot.ts, and the Git service now uses a per-process temporary index (withTemporaryIndex — "Processes never contend on index.lock") plus a cross-process opencode-pack.lock for packing. So that is not the cause.

    What still stands from my diagnostics: a single OpenCode workspace had 10 TUI instances, a single background service, and a 368 MB SQLite DB that was ~60% free pages (VACUUM shrank it to 146 MB). Please treat this as a symptom report — several instances in VS Code terminal tabs freezing together on tab switch. Happy to collect more data (service logs, a repro) on request.

  4. opencode-agent commented on Oct 14, 2026

    @opencode-agent
    opencode-agentBot
    on Oct 14, 2026 – with OpenCode Agent
    Contributor

    Thanks for the correction, and for checking the snapshot code on dev. Treating this as a symptom report works for us.

    Since you offered to collect data: we still can't reproduce this, because we don't know what the shared service is doing while the TUIs are frozen. Next time it happens, before you restart the service, could you share:

    1. CPU of the opencode serve --service process (top -pid <pid> or Activity Monitor). Is it near 100% or idle?
    2. Does the service answer? Run curl -m 5 <url from opencode service status>. Does it respond, and how fast?
    3. Log lines from the minute or two around the freeze in ~/.local/share/opencode/log/opencode.log, especially any Event stream stalled or Background service is unresponsive lines.
    4. Does opencode --standalone avoid it with the same workflow?

    You shrank the database with VACUUM, so it's also worth noting whether the freezes still happen afterwards (with every client on 2.0.29). If they stop, that points to the database. If they continue, it points somewhere else, closer to #54181 or #52049.

  5. opencode-agent commented on Oct 17, 2026

    @opencode-agent
    opencode-agentBot
    on Oct 17, 2026 – with OpenCode Agent
    Contributor

    We're closing this for now because we haven't received the diagnostics we'd need to reproduce it. That's what the service was doing during a freeze: its CPU use, whether the service URL still answered, the log lines from around the freeze, and whether --standalone or the VACUUM made a difference.

    If it happens again, please reply with those details and we can reopen it. Or follow the closely related reports in the meantime: #54181 (the service stops answering on macOS) and #52049 (Event stream stalled makes the client replace the service). Thanks for the thorough initial investigation!

  6. opencode-agent
    closed this as not plannedon Oct 17, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    triaging

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions