[Linux Desktop 26.820.60940] New local tasks hang at “Starting your task” after AppServerManager RPC disconnect
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 125k
- Forks
- 19.4k
- PR merge metrics
- PR metrics pending
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Codex Desktop 26.820.60940
What subscription do you have?
Pro
What platform is your computer?
Ubuntu 24.04, x86_64
What issue are you seeing?
Codex Desktop cannot start new local tasks. A new conversation remains indefinitely at:
- “Loading branch”
- or “Starting your task”
The task never begins. Codex CLI works from the same machine and repository.
Desktop logs show the AppServerManager RPC connection being torn down or becoming unavailable:
AppServerManager RPC is not connected
RPC session was shut down by disposing the main stub
response_orphaned ... transportKind=stdio
No promise for request ID
In some launches, an account-settings request initially returns HTTP 401 before later returning 200. The RPC connection does not appear to recover afterward.
This appears related to the authentication/AppServerManager lifecycle failures reported in:
- https://github.com/openai/codex/issues/39677
- https://github.com/openai/codex/issues/40197
- https://github.com/openai/codex/issues/39850
Unlike those reports, this is occurring on Linux and continues after upgrading to Desktop 26.820.60940.
Troubleshooting already performed
- Fully quit and restarted the desktop app.
- Signed out and signed back in.
- Upgraded from 26.818.61809 to 26.820.60940.
- Verified Codex CLI 0.149.1 works.
- Reproduced in a newly created minimal Git repository.
- Corrected and verified the original repository/worktree state.
- Checked configured MCP servers; they initialize successfully.
- Did not find MCP OAuth lock-timeout or token-reading errors.
- GitHub CLI failures in the logs were limited to optional PR-status probing and do not explain the failure in an empty repository.
What steps can reproduce the bug?
- Open Codex Desktop on Ubuntu.
- Open a local Git repository.
- Start a new chat/task.
- Observe “Loading branch” or “Starting your task.”
- Wait indefinitely; the task does not start.
The problem also reproduces with a newly created minimal Git repository, so it does not appear specific to the original repository or its worktrees.
What is the expected behavior?
The app should establish or restore its AppServerManager RPC connection and start the local task.
If authentication needs to be refreshed, the app should refresh it or present an actionable authentication prompt.
Actual behavior
The task remains indefinitely at “Loading branch” or “Starting your task.”
Restarting the app, signing out and back in, and upgrading the desktop app do not reliably resolve it. Signing out previously caused a full-page “Oops, an error occurred” screen.
Additional information
The original project uses multiple Git worktrees. During failed startup attempts, Codex Desktop has sometimes detached the project-root checkout at HEAD, apparently while attempting to create task isolation. Correcting the checkout does not prevent the failure from recurring.
This looks like a consequence of task startup failing rather than the root cause, because the same hanging behavior occurs in a minimal repository without worktrees.
Please let me know if there is a diagnostic bundle or additional app-server tracing I can collect.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the hang in Codex Desktop on Ubuntu with a minimal Git repository, then inspect the AppServerManager RPC lifecycle around “Loading branch” and “Starting your task.” Use the listed RPC, authentication, and response-orphaned log messages to trace startup failure and recovery. Done means a new local task starts reliably or an actionable authentication prompt appears after the connection is lost.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- linux, rust
- Domain
- authentication, backend, desktop
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100