TUI may show activity from another concurrent session in the same repo

[cbusillo]

What issue are you seeing?

Suspected TUI/session isolation leak: the active Every Code CLI TUI appeared to show activity from another concurrently running session in the same launchplane repository/workspace.

This is not yet proven as a rendering-layer bug, but we have a concrete timestamped case where the user saw new TUI activity after the active session had reported completion, and subsequent verification showed that the new activity corresponded to a different Launchplane workstream/session merging PR openai#948, not the active preview-fix session.

Impact: this can make users believe the current agent/session is still acting, merging, or running workflows when the activity belongs to another session. That is especially risky around merge/deploy operations.

What steps can reproduce the bug?

Observed scenario:

1. Run at least two Every Code CLI sessions against the same repo/workspace (/Users/cbusillo/Developer/launchplane).
2. Session A was scoped to a VeriReel preview fix.
3. Session B was separately working on Launchplane JSON file overlay work.
4. Session A merged its final preview follow-up PR and reported done.
5. The user then saw more activity in Session A's TUI and asked whether the TUI was delayed or whether there had been more activity.
6. Session A verified the live GitHub state and found real new activity, but it belonged to Session B's workstream.

Machine-verifiable timeline from GitHub:

• 2026-05-28T19:45:23Z: PR history doesn't work in headless mode openai/codex#950 merged in cbusillo/launchplane, preview-fix follow-up: Classify existing VeriReel preview fetch outages launchplane#950
  • merge commit: 3fb3212f8535e49b6f9d4b84e7d63e63691ad647
• 2026-05-28T19:47:55Z: Deploy Launchplane run queued for PR history doesn't work in headless mode openai/codex#950 merge commit: https://github.com/cbusillo/launchplane/actions/runs/26598256005
• 2026-05-28T19:50:32Z: PR chore: introduce AppEventSender to help fix clippy warnings and update to Rust 1.87 openai/codex#948 merged in cbusillo/launchplane, separate JSON-file-fields workstream: Allow Launchplane request JSON file overlays launchplane#948
  • merge commit: 0ba0970a449d9668b7e71ffd6c530d2fd8640109
• 2026-05-28T19:50:35Z: Fresh CI/Security/CodeQL runs started on main for PR chore: introduce AppEventSender to help fix clippy warnings and update to Rust 1.87 openai/codex#948's merge commit.

Commands used to verify the timeline from Session A:

gh pr view 950 --repo cbusillo/launchplane --json number,title,mergedAt,mergeCommit,url,headRefName
gh pr view 948 --repo cbusillo/launchplane --json number,title,mergedAt,mergeCommit,url,headRefName
gh run list --repo cbusillo/launchplane --branch main --json databaseId,name,status,conclusion,headSha,createdAt,updatedAt,url --limit 8
git -C /Users/cbusillo/Developer/launchplane log --oneline --decorate --max-count=8 origin/main

Relevant observed output:

PR #950 mergedAt: 2026-05-28T19:45:23Z, mergeCommit 3fb3212f...
PR #948 mergedAt: 2026-05-28T19:50:32Z, mergeCommit 0ba0970...
main runs at 2026-05-28T19:50:35Z were for headSha 0ba0970..., not PR #950's 3fb3212f...

What is the expected behavior?

A TUI session should only display activity/events belonging to that specific session unless it clearly labels cross-session or repo-global events as such.

For example, if another session merges a PR or starts GitHub Actions, Session A should either:

• not show that activity, or
• show it in a separate explicitly labeled cross-session/global activity area with session/worktree/agent identity.

What do you see instead?

The user saw new activity in Session A's TUI after Session A reported its scoped task complete. Verification showed there really was new repository activity, but it was from a different session/workstream (openai#948), not Session A's preview-fix work (openai#950).

We cannot yet distinguish whether the cause is:

• event bus messages not being scoped by session id,
• a repo/workspace-level watcher feeding all sessions,
• delayed rendering of old actions combined with new repo events,
• shared auto-review/GitHub status notifications landing in the wrong TUI,
• or the TUI presenting repo-global activity without clear attribution.

Additional information

Environment:

• code --version: code 0.6.106
• platform: Darwin 25.5.0 arm64 arm
• repo/workspace involved: /Users/cbusillo/Developer/launchplane
• multiple Code sessions were open for the same Launchplane repo.

This report is intentionally phrased as suspected because we verified the GitHub-side activity and timing, but not the internal event routing source. The useful fix may be stronger session IDs on event messages, clearer attribution in the TUI, or filtering repo-global notifications out of per-session activity streams.

[cbusillo]

Follow-up from the #197/#198 workstream: I found and fixed two more session-isolation paths in PR #199.

Evidence/fix summary:

• The agent HUD was already filtered by Fix session-scoped agent status updates #197, but model-facing agent operations (agent list, status, result, wait, cancel, and Op::CancelAgents) still used global manager lookups. That could let Session A discover or operate on Session B agents when batch ids overlapped or an agent id leaked into context.
• Background shell completion wakeups used a process-global TX_SUB_GLOBAL sender. Because it was a OnceLock, the first spawned session could receive developer wakeups for later sessions background shell completions. This is a concrete match for the kind of confusing cross-session activity described here.
• PR Scope background activity to the owning session #199 scopes those operations to sess.session_uuid() and queues background shell completion wakeups directly on the originating session instead of a global sender.

Validation on the branch:

• cargo test -p code-core model_facing_agent_queries_are_session_scoped
• cargo test -p code-core agent_status_updates_include_only_owned_agents
• cargo test -p code-core --test agent_completion_wake concurrent_same_repo_sessions_only_receive_owned_agent_status
• cargo test -p code-core --no-run
• ./build-fast.sh

PR: #199

[cbusillo]

Follow-up to PR #199: auto-review found a reconnect edge case where archived terminal agents could be cleared after all UI senders disconnected and a later sender registered.

I agreed with the finding and opened PR #200. The fix tracks whether the event-sender lifecycle has ever started, instead of treating an empty live-sender list as a brand-new manager lifecycle. That preserves archived completed agents across UI reconnect/resume gaps.

Validation:

• cargo test -p code-core reconnect_after_sender_gap_keeps_existing_archived_agents
• cargo test -p code-core registering_second_session_keeps_existing_archived_agents
• ./build-fast.sh

PR: #200

[cbusillo]

Fixed by #199 and follow-up #200. Evidence: PR #199 scoped model-facing agent operations and background completion wakeups to the originating session; PR #200 preserved archived agent state across UI reconnects. Main Release passed after both merges: https://github.com/cbusillo/code/actions/runs/26636611343