Codex Mobile remote new thread cannot choose worktree or starting branch
Summary
When starting a new Codex task from Codex Mobile / ChatGPT mobile connected to a Mac running the Codex App, I can choose the project and adjust model / permissions, but I do not see a way to choose:
- Local vs Worktree execution
- the starting Git branch
- an existing or permanent worktree target
This is a workflow and safety problem for local development. From mobile, it is easy to accidentally start work against the primary local checkout, for example main, instead of an isolated worktree or intended feature branch.
Why this matters
The mobile remote-control feature is most useful when I am away from the Mac and want to start or supervise work asynchronously. In that context, I often cannot easily inspect the host machine’s current Git state before sending the first prompt.
For serious repositories, the execution target is not a cosmetic setting. Before an agent starts editing files, I need to know and control:
- which checkout it will modify
- whether it will use an isolated Codex-managed worktree
- which branch or commit the worktree starts from
- whether the selected project is my foreground local checkout, a permanent worktree, or some other workspace
Prompt-level guardrails like “run git status first and stop if unexpected” help, but they are weaker than first-class UI selection and confirmation. The unsafe case is that a mobile-created thread starts in a checkout I did not intend, and I only notice after files have already changed.
Steps to reproduce
- On a Mac, open the Codex App and enable mobile remote control.
- On an iPhone, open ChatGPT > Codex mobile and connect to that Mac host.
- Start a new thread from the mobile UI.
- Select a local Git repository project on the host.
- Open the available controls in the composer.
Actual behavior
The mobile new-thread UI lets me select the project and configure model / reasoning / permissions, but I do not see controls equivalent to the desktop Codex App worktree flow:
- no Local vs Worktree selector
- no starting branch selector
- no explicit confirmation of the effective checkout / worktree / branch that will receive edits
The UI therefore does not make it clear whether the task will run in my primary local checkout or in an isolated worktree.
Expected behavior
Codex Mobile should provide parity with the Codex App new-thread workflow for Git-backed projects, or clearly state that the mobile flow is limited.
At minimum, before submitting a mobile-created task, the UI should let the user choose:
- Local checkout vs Worktree
- Starting branch for worktree creation
- Existing / permanent worktree when the host has one registered as a project
It should also show a clear pre-submit execution target, for example:
- project path or repo root
- current branch, detached HEAD, or selected base branch
- whether the run will use Local or a Codex-managed worktree
- the worktree path when known
A conservative option would be to require an explicit confirmation when starting from mobile against a protected or primary branch such as main / master.
Related documentation / context
The Remote Connections docs say mobile can start new threads in projects on the connected host:
https://developers.openai.com/codex/remote-connections
The Worktrees docs describe the desktop flow where a new thread can select Worktree and choose the starting branch:
https://developers.openai.com/codex/app/worktrees
From a user’s point of view, these two features naturally overlap: if mobile can start a new local task on the Mac host, it should also expose the same Git target controls that make desktop local tasks safe.
Possibly related issues, though not exact duplicates:
- #19681 asks for iOS/Mac session continuity including current branch/session context.
- #16531 covers cases where the thread UI can drift from the actual worktree / branch context.
- #20757 requested broader mobile companion support for local, worktree, and cloud tasks.
Workarounds
Current workaround is to manually create a dedicated worktree on the Mac host and register it as a separate project, then select that project from mobile. I also have to add prompt instructions such as:
First run git status --short --branch and git rev-parse --show-toplevel. If the branch/path is not the expected worktree, stop and ask before editing. Do not create or switch branches unless explicitly requested.
This works only as a discipline, not as a safe product affordance.
Requested outcome
Please add first-class branch / worktree targeting to Codex Mobile remote new-thread creation, or document the current limitation explicitly so users understand that mobile-created local tasks may start in the selected project’s current checkout.
6 Comments
Ran into the same bug. According to my experience, codex does the worst thing possible and it will reuse the last environment created on the desktop, which will mess up work in progress on an entirely different worktree. Hope this gets fixed soon.
Dynamic worktree creation from iOS to MacOS desktop is a high value affordance, and same over other combinations of mobile and desktop app would be similarly.
I have to start new "chats" on desktop, to cretae several new worktrees + run "bootstrap" scripts.
I havew another problem too, mobile app does not see several projects which i have added to codex desktop and using every day.
+1
This has been a real blocker for me while working on the iOS app connected to a VPS via SSH. I can ask the chat to work on an isolated worktree, but it's not deterministic and won't automatically clean it up like the desktop app does.
Adding a related data point from Android Mobile Remote + Codex Desktop on macOS. This looks like the same underlying problem @stemps mentioned above, with local evidence that the issue is specifically the mobile
Workspacepath.In my local repro, using Mobile Remote with
Workspacemode created a new thread whose execution cwd was an existing Codex-managed worktree:~/.codex/worktrees/<worktree-id>/<repo>rather than the canonical checkout:
/Users/<user>/repos/<repo>There were no
worktree-create/ path allocation logs for that thread, so this was not a newly-created worktree. It appearsWorkspacemode simply reused the selected project/workspace cwd, and for this project that cwd pointed at a previous Codex-managed worktree.The practical problem is that Mobile
Workspacemode does not give me a reliable way to say:main/masterSo if the selected project entry has drifted to a Codex worktree cwd, Mobile
Workspacecan silently start a new task in that old worktree. The workaround is to chooseWorktree, but that changes the execution model instead of letting me work intentionally in the normal checkout / branch.Expected behavior:
Workspaceshould clearly mean the canonical/local checkout, or explicitly show when it is actually a worktree path.