Wrong TUI leaks into session

Codex
,
1

Sometimes throws an error “Not available in TUI yet for thread ***”, and then I can arrow-roll to prompts from another active session. Sometimes it even dies on it (one session quit unexpectedly, while another still runs). It does not hurt, it seems the background agents actually continue doing their tasks correctly, and it can be resumed after the crash.

2

I am not OpenAI staff, but this sounds like a state/routing bug between active Codex CLI sessions rather than a task failure.

A few details would make it easier to reproduce: Codex CLI version, terminal app, OS, whether both sessions were started from the same repo/worktree, and whether the error appears after resuming a thread or while both sessions are live.

A minimal repro would be especially useful: start session A, start session B, leave both running, then note which keypress/action causes prompts from B to appear in A. Since you said the background tasks keep running, I would include that too, because it separates UI/session routing from agent execution.

For now, I would avoid running multiple TUI sessions in the same terminal/tmux context and use separate terminal windows or worktrees when possible.

3

Thanks! Recent cleaner occurrence:

  1. codex-cli 0.133.0
  2. zsh
  3. MacOS Tahoe 26.4.1
  4. sessions were started from different repos (and kept different worktrees): this is what prompted my attention as I was able to see history from repo A job in repo B after the TUI error message
  5. both sessions were alive (executing at the same time from different terminals)
  6. there was no apparent key action to trigger the error. the TUI error would produce a message and abort session B. then I would investigate and be able to see the prompt history from A in B. The prompts were really different in nature, easy to spot the discrepancy.
4

Possible technical cause of the “wrong TUI leaks into session” bug:

  • PTY/shared terminal sessions not fully isolated
  • stdout/stderr streams multiplexed incorrectly
  • incorrect reuse of session_id or websocket state
  • race conditions during session attach/detach
  • cached UI state not reset when switching agent/session
  • possible cross-talk between TUI renderer and backend event bus

Things worth checking:

  • strict per-PTY isolation
  • full cleanup on disconnect
  • renderer state invalidation
  • strong binding between user/session/terminal
  • locking around concurrent streams
  • separate namespaces for TUI state

This looks more like a session orchestration issue than an AI model issue itself.