Codex Desktop: Computer Use follows the foreground Codex project window and can act in another project's terminal
Summary
When multiple top-level Codex Desktop project windows are open, a Computer Use task started from Project A can follow the user's foreground focus to Project B while it is waiting or running. When the task resumes, its clicks or keyboard input may be applied to Project B's terminal or UI instead of the originating Project A window.
This is more than a wrong-screenshot problem: it can cross project, repository, terminal, and SSH authorization boundaries.
Environment
- Codex Desktop: 26.727.51351 (6119)
- macOS: 26.5 (25F71)
- Workflow: multiple top-level Codex project windows, each with a different thread/repository and terminal context
Steps to reproduce
- Open two separate Codex Desktop project windows, Project A and Project B.
- In Project A, start a Computer Use task that needs to interact with Project A's bottom terminal or another project-local pane.
- While Computer Use is waiting or running, switch to Project B and continue unrelated work there.
- Let the Computer Use task from Project A resume.
- Observe that Computer Use can follow the newly foregrounded Codex window and interact with Project B instead of remaining bound to Project A.
Actual behavior
UI focus appears to become an implicit routing key. Switching the foreground Codex window can retarget an in-progress Computer Use task even though its originating thread and project did not change.
Observed impact in one real workflow (sanitized):
- An SSH terminal intended for one project was shown under a different Codex project window.
- Attempts to recover visibility created extra terminal tabs.
- Text intended for a remote model was delivered to a shell and produced a command not found result.
- No destructive command succeeded in this incident.
I have not deliberately repeated this reproduction after identifying the risk, because a controlled retry could operate another repository, SSH session, or private project.
Expected behavior
Computer Use should remain bound to the task that launched it. User focus changes must not alter that binding.
For Codex Desktop multi-window workflows, the target identity should include at least:
- originating thread/task ID;
- top-level Codex window ID;
- project/worktree identity;
- terminal/session ID when a terminal is targeted;
- intended target app/window.
Before every click or keyboard action, Computer Use should validate that the current target still matches this binding. If it cannot validate the target, it should fail closed and ask the user to restore the correct window rather than acting on the foreground window.
The UI should also display which project/window/terminal Computer Use is currently authorized to operate.
Impact
- Commands or prompts can be sent to the wrong shell or SSH host.
- Unrelated project files or private content may be exposed or modified.
- Users cannot safely work in another Codex project while a Computer Use task is waiting.
- Recovery attempts can create duplicate terminal sessions and increase confusion.
Related issues
- #21668 — wrong macOS Space/window targeting
- #24301 — unrelated windows captured instead of the target window
Those reports focus primarily on capture/screenshot drift. This report focuses on action routing between two project windows inside the same Codex Desktop app.