CLI: command approval dialog leaks into unrelated Codex sessions across worktrees #48349

What version of Codex CLI is running?

codex-cli 0.157.1

What subscription do you have?

Not disclosed.

Which model were you using?

gpt-6-sol in the requesting thread. Other Codex sessions were open concurrently.

What platform is your computer?

Linux x86_64 (uname -mprs: Linux 7.2.7-1-cachyos-server x86_64 unknown). Multiple Codex CLI TUIs ran in separate Herdr 0.9.1 panes, each in a different Git worktree.

What terminal emulator and version are you using?

Herdr 0.9.1 multiplexed the Codex panes. Outer terminal details were not captured.

Codex doctor report

codex doctor --json completed. Overall status was warning because config.load reported an unrecognized configuration setting; config parsing succeeded. The full report is withheld because it includes local paths and configuration metadata. No notify or tui.notifications override is configured.

What issue are you seeing?

A command-approval dialog belonging to one Codex thread is rendered inside other Codex CLI sessions in unrelated worktrees. A 38-second screen recording shows the same modal's Thread: Agent (<same thread ID>) field in at least two different Codex panes that visibly contain unrelated conversations. The requested command changes as the originating thread makes subsequent requests, but the unrelated panes show the new approval modal too.

Herdr then marks those panes as Action Required, apparently because their terminal screens now contain a real Codex approval dialog. The reporter also hears spurious completion sounds when the originating thread finishes; the video supports the approval/UI and Herdr state behavior, but does not establish the sound's underlying event path.

This is not just a notification banner: the full interactive Would you like to run the following command? dialog, with Yes/No choices, appears in a different session's TUI. I did not test whether accepting from the wrong pane executes the command, so approval execution crossing remains unconfirmed. Nevertheless, the UI makes it hard to know which session owns the requested command.

What steps can reproduce the bug?

1. Open multiple Codex CLI sessions in separate Herdr panes, each in a distinct Git worktree and with a different conversation.
2. In session A, request a command requiring user approval; leave the dialog pending.
3. Focus session B and then session C. In the recording, an approval modal with the same Thread: Agent ID from A is visible over each unrelated conversation, and Herdr labels multiple panes Action Required.
4. Resolve or dismiss the pending approval. The cross-pane modal disappears and Herdr's sidebar state changes again.

The issue was observed with several panes open. The screen recording includes private project text and paths, so it is not attached publicly. A redacted excerpt can be prepared if maintainers need it.

What is the expected behavior?

Only the Codex session that owns the command request should render its approval dialog. Other sessions should continue displaying their own conversation and should not become actionable due to a foreign thread's request. If cross-session approval notification is intentional, it should identify the owning thread and must not replace another session's interactive TUI state.

Additional information

• The Herdr Codex integration installed here reports session identity only via SessionStart. Herdr's Codex lifecycle state is screen-detected; the same foreign approval dialog was visibly present in the Codex panes themselves. This makes Herdr's simultaneous Action Required labels a downstream effect rather than proof of a Herdr routing defect.
• Codex's tui.notifications = false setting can suppress Codex TUI notifications, but it does not explain or fix an interactive approval modal rendered in another thread's terminal.
• I found no clearly equivalent open or closed Codex CLI issue. Related but different: Rogue approval across Codex sessions plus frozen/stale TUI after interrupt #30714 concerns suspected cross-session approval execution after an interrupted Windows task; this report is directly observable cross-session approval UI rendering on Linux, without claiming cross-session execution.