Parallel Codex sessions become unusable due to repeated approval prompts
What issue are you seeing?
I tried running multiple Codex sessions in parallel using separate Git worktrees for independent development tasks.
The expectation was that each Codex session could continue working independently while I focused on another task.
However, both sessions repeatedly stopped and waited for approval during normal development work.
Even with only two concurrent sessions, I had to stay in front of the screen and continuously respond to approval requests. Instead of allowing me to delegate work and move on, the parallel workflow turned into managing approval requests.
The practical impact was:
- I could not safely delegate tasks and leave them running.
- I had to monitor whether Codex was still working or waiting for approval.
- Running multiple agents increased coordination overhead instead of improving productivity.
The main value of parallel agents is that users should be able to delegate multiple tasks and focus elsewhere. Currently, frequent low-value approvals make the user the synchronization point for the agents.
What steps can reproduce the bug?
- Create multiple Git worktrees for independent tasks.
- Start multiple Codex sessions, one per worktree.
- Assign independent development tasks to each session.
- Allow them to run concurrently.
- Observe repeated approval prompts interrupting normal progress.
What is the expected behavior?
When a task is explicitly delegated to a Codex session in its own worktree, routine development operations should continue without requiring constant human interaction.
Approval should remain for meaningful boundaries, such as:
- destructive operations;
- security-sensitive actions;
- actions outside the assigned workspace;
- external side effects;
- decisions that require human judgment.
The purpose of parallel agents is to reduce context switching and allow users to focus on higher-level work. Approval frequency should not become the bottleneck that prevents this workflow.
Additional information
This is not a request to disable security controls.
The issue is that approval frequency becomes the bottleneck when using multiple agents in parallel. Even at a concurrency of only two sessions, the user becomes the synchronization point for the agents.
Final note
I have been using OpenAI products since the early days of ChatGPT, and I still remember the excitement of experiencing technology that felt like it could fundamentally change the way we work.
I am reporting this issue not because I have lost confidence in Codex, but because I believe in its potential.
I hope Codex can continue evolving toward the kind of experience many of us felt when we first encountered ChatGPT: the feeling that the way we work had fundamentally changed.
Thank you for continuing to build and improve this technology.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
A likely concrete mechanism behind "constant approvals in parallel worktrees", plus the two existing levers:
In a linked git worktree, the worktree's
.gitis a pointer file into the main repo's.git/worktrees/<name>— which lives outside your worktree's workspace-write root. So every git mutation (commit, branch, even some status paths that touch the index) escapes the sandbox root and escalates to an approval, per session, forever. That's tracked as #38672 (:root = "deny"making the resolved linked-worktree git directory unreadable); until codex auto-includes the resolvedgit common dirin the writable roots for worktree sessions, you can approximate it with[projects."<path>"]/workspace-write config adding the main repo's.gitto writable roots. If your approvals are mostly git commands, this one change removes most of them.The second lever is
approvals_reviewer = "auto_review"("Approve for me"): a guardian model reviews and approves routine sandbox-boundary requests so you stop being the synchronization point, while denials still surface (noise concern tracked in #38112). Between the worktree-root fix and auto-review, the delegate-and-walk-away workflow you're describing is mostly reachable with today's machinery — the gap is that neither is on by default nor suggested when codex detects a linked worktree.+1 this is happening constantly.