tui: with tabs.scope=global, every new CLI launch rewrites the shared tab strip and silently drops previously open tabs #60859

Activity

1. opencodejr commented on Oct 31, 2026

   

   opencodejrBot

   on Oct 31, 2026

   More actions

   Thanks for the detailed report. I tried to reproduce this on 2.2.4 and couldn't.

   What I tried, with cli.json set to { "tabs": { "scope": "global" } }:

   1. Opened three sessions as tabs in one TUI. latest/tui/tabs.json had 3 entries in global.tabs.
   2. Started a second, fresh TUI while the first was still running and created a session. The file then had 4 entries, and the first TUI's tabs were still there.
   3. Closed that one, then started three throwaway TUIs one after another, each creating a session and exiting. The file ended with all 7 tabs, and the first TUI's strip still showed its own tabs plus the new ones.

   That matches how the code is meant to work: each tab change takes a file lock, re-reads tabs.json from disk and adds to it rather than replacing it. Tabs are only removed when you close one or the session is deleted.

   My setup differs from yours in a few ways: Linux rather than macOS/iTerm/tmux, all instances started from the same directory, and a dedicated server rather than the shared background service. Any of these would help narrow it down:

   • A copy of tabs.json from just before and just after a launch that drops tabs (session IDs are fine to share). Please also say whether the "after" file still parses as valid JSON.
   • Whether the first terminal was still running, or had exited, when the other instances were launched.
   • Whether those instances were plain opencode, or used -s, --continue, --server or similar flags.
   • Whether you closed tabs in any instance (<leader>w or the tab menu) or deleted sessions around that time.
   • Any Failed to persist session tabs errors in the logs.

   Related, but not the same problem: #52080 and #47998 (global tabs shared across different servers), and #48635 (request for tab history and recovery).
2. turian commented on Oct 31, 2026

   

   turian

   on Oct 31, 2026

   Author

   More actions

   Update: we attempted to reproduce this on the originally reported platform and could not reproduce the drop either. We're withdrawing the "every new launch rewrites the strip" characterization from the original report — it was stronger than our evidence supports.

   Environment

   OpenCode 2.2.4, macOS arm64, iTerm2 + tmux 3.x, default shared background service, cli.json → {"tabs": {"scope": "global"}}.

   Method

   Byte-for-byte snapshots of tabs.json (content + inode/size/mtime + SHA-256 + JSON-validity check) taken immediately before and after each action against a live strip holding 16–19 open tabs; the diff is the set difference of sessionIDs computed from the copies, not the live file.

   Trials and results

   #	Action	Added	Removed
   1	plain opencode launch (home screen) from a different directory	—	none
   2	opencode -s <existing-session-id> from a different directory	the opened session	none
   3	kill -9 the TUI process owning a tab, then launch another instance elsewhere	—	none — the killed instance's tab persisted
   4	graceful exit (ctrl+c = app.exit) of a TUI owning a tab	—	none — the tab persisted
   5	isolated service + --standalone TUIs	strip never written at all	—

   No condition we can construct — including unclean termination — drops previously open tabs. Merge-on-write appears solid in all tested topologies. One side observation from trial 5: --standalone instances never write the strip; persistence appears to require the shared-service topology.

   For completeness: the sessions behind our originally "missing" tabs were never lost (verified directly in the database: all present, zero archived, zero deleted) — the incident impact was confined to the tab strip view.

   What we can and cannot say about the original incident

   We no longer have a before-copy, and by the time we investigated, the fleet of TUIs involved had already exited (exit times and causes unlogged), so we cannot reconstruct what the strip held beforehand or prove a drop occurred. It is possible the original report over-interpreted "sessions not in the strip" as data loss combined with an unrelated strip change.

   Two code paths we'd still flag as capable of producing the observed end state (a file containing only the most recent writer's tabs, with no error surfaced):

   1. Read-failure fallback: if reading the tab store fails (permissions, truncation, partially-written file), a fallback to initial/empty state followed by a normal merge-write would produce exactly that file silently. Our logs contained no Failed to persist session tabs errors, but a silent fallback presumably wouldn't log.
   2. Stale-snapshot replace on reopen: reopening a closed tab appearing to replace the list from a previously computed client snapshot would drop tabs added in between.

   If there is a debug flag, log level, or instrumented build that logs each strip write (writer PID/version, mutation type, read outcome, before/after hashes), we're willing to run it and report back. Otherwise happy to close as not-reproducible.
3. opencodejr

   closed this as not plannedon Nov 3, 2026
4. opencodejr commented on Nov 3, 2026

   

   opencodejrBot

   on Nov 3, 2026

   More actions

   I'm closing this for now because we couldn't reproduce it and haven't heard back. On 2.2.4 with tabs.scope: "global", a fresh TUI launch (with the first one running or closed, and several quick launches in a row) added its tab to tabs.json. All earlier tabs stayed in the file and in the first TUI's tab strip.

   If it happens again, please reopen or comment here with:

   • a copy of tabs.json from just before and just after a launch that drops tabs
   • whether the first terminal was still running at the time
   • the exact launch command and flags
   • any Failed to persist session tabs errors in the logs

   With those we can take another look. Thanks for the detailed report.