Skip to content

Linux desktop 26.924.22138 stays on “Starting your task” and leaves exited helper processes unreaped #48640

Closed
Closed
Linux desktop 26.924.22138 stays on “Starting your task” and leaves exited helper processes unreaped#48640
Labels
LinuxappIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archiving

Description

@UAVWangTao
UAVWangTao
opened on Sep 27, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

26.924.22138, verified from the installed official Debian package metadata and desktop logs. The About dialog was not separately checked.

Bundled Codex backend: codex-cli 0.158.0-alpha.2.1.

What subscription do you have?

Pro

What platform is your computer?

Linux 7.0.0-34-generic x86_64 x86_64

Ubuntu 24.04.5 LTS, using the official Linux desktop .deb package.

What issue are you seeing?

After installing the newer desktop version, the Codex UI stays on “Starting your task”. Existing local conversations also fail to finish loading.

The local app-server initializes successfully and responds to ordinary metadata requests, but desktop logs report a shell-environment timeout, a thread-hydration timeout, and “Git is unavailable.” Git itself works outside the desktop app.

These are selected, verbatim log fragments with all identifying fields omitted. They are not complete log lines or a single contiguous trace:

Failed to load shell env caller=startup detail="Timed out after 5000ms."
name=thread_hydration outcome=failure reason=timeout
Worktree archive will be retried errorMessage="Git is unavailable"

Process inspection showed exited zsh, git, and ssh helpers remaining in zombie (Z) state under the desktop process. This persisted across ordinary desktop restarts. A login-shell probe outside the desktop app returned successfully in approximately half a second; the system Git executable also ran successfully.

What steps can reproduce the bug?

On the affected installation with existing local Codex state:

  1. Install desktop version 26.924.22138 and launch it normally.
  2. Open Codex and select an existing local conversation.
  3. Observe that the conversation remains in the starting/loading state instead of becoming ready.
  4. Fully exit and restart the desktop application, then open the conversation again. The failure persists.
  5. Inspect the desktop logs and child-process states while it is stuck: the timeout messages and unreaped helpers described above are present.

These steps describe the affected installation; I do not yet have a clean-profile minimal reproducer. No private prompt or project content is required to describe the failure. Conversation/session IDs are omitted for privacy. Token and context-window usage were not established as relevant to this startup failure.

What is the expected behavior?

Existing local conversations should become ready for use. The desktop app should recognize helper-process completion and should not report an installed, working Git executable as unavailable. If initialization fails, the UI should show an actionable error rather than remain indefinitely in a starting/loading state.

Additional information

Local comparison and its limits:

  • Ordinary restarts of 26.924.22138 did not resolve the failure.
  • An isolated startup of the previously downloaded desktop version 26.825.41651 did not show the same persistent zombie helpers.
  • A temporary recovery setup used the 26.825.41651 desktop interface with the current 0.158.0-alpha.2.1 backend, a separate desktop browser profile, and the existing Codex history. Local thread/project metadata had already been repaired before this recovery test.
  • In that recovery setup, shell-environment loading completed in approximately half a second, the observed Git error was absent, and existing conversations returned successful thread/resume responses followed by maybe_resume_success.
  • A complete new model-response turn was not tested during these diagnostics.

Because the desktop version, browser profile, and project-assignment state differed between the original failure and the recovery setup, this is not a controlled version-only comparison. It does not establish the precise cause or rule out a profile/state contribution. Unreaped helpers are an observed symptom, not proof of a particular libuv, Electron, kernel, or backend defect. The mixed-version recovery setup is temporary and is not claimed to be officially supported.

Potentially overlapping reports:

No raw logs, state databases, configuration files, authentication data, or conversation transcripts are attached.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on Sep 27, 2026

  2. github-actions commented on Sep 27, 2026

    @github-actions
    github-actionsBot
    on Sep 27, 2026 – with GitHub Actions
    Contributor

    Potential duplicates detected. Please review them and close your issue if it is a duplicate.

    Powered by Codex Action

  3. linear
    added
    Linux
    on Sep 27, 2026

  4. Marcos020912 commented on Sep 27, 2026

    @Marcos020912
    Marcos020912
    on Sep 27, 2026

    Try using the Codex CLI while they fix the bug; it's not as powerful as the graphical app, but it solves the problem in the meantime. To integrate the browser, install the ChatGPT Chrome extension and configure it to control Chrome browser tabs, and enable remote debugging in Chrome.

  5. jwminer commented on Sep 27, 2026

    @jwminer
    jwminer
    on Sep 27, 2026 – with ChatGPT Codex Connector

    Another reproduction on Linux with the official Debian package 26.924.22138:

    • Existing Codex conversations appear in the sidebar, but selecting them leaves the loading spinner.
    • New Codex tasks remain at “Starting your task”; ordinary ChatGPT conversations can reply in the same app.
    • Desktop logs show a successful account lookup and successful thread/read, followed by “Conversation state not found” and maybe_resume_started. They also show a shell-environment timeout and “Workspace routing is unavailable” responses.
    • The failure persisted in a temporary desktop user-data profile. dpkg --verify chatgpt reported no package-file differences.

    No raw logs, account details, local paths, conversation IDs, host identifiers, prompts, or workspace contents are included.

  6. sv-service commented on Sep 28, 2026

    @sv-service
    sv-service
    on Sep 28, 2026 – with ChatGPT Codex Connector

    Confirmed on another Ubuntu installation.

    Affected desktop package:
    chatgpt 26.924.22138 amd64

    Observed symptoms after updating to 26.924.22138:

    • Existing Codex chats hang on an infinite spinner while opening.
    • New messages are not sent or remain queued.
    • The queued task can stay visible indefinitely.
    • Restarting the app did not resolve the issue.

    A/B recovery test on the same machine:

    • Downgraded only the ChatGPT/Codex desktop package to the cached previous build:
      26.917.62051
    • Kept the existing local Codex state/history.
    • After downgrade, Codex immediately started working normally again: existing chats opened and messages could be sent.
    • The package was then held with sudo apt-mark hold chatgpt to prevent re-upgrade.

    Commands used for the successful workaround:

    sudo apt-mark unhold chatgpt
sudo apt install --allow-downgrades -y /var/cache/apt/archives/chatgpt_26.917.62051_amd64.deb
sudo apt-mark hold chatgpt

    This is a fairly clean version-only comparison on the same Ubuntu system and same local user state:
    26.924.22138 broken -> 26.917.62051 working.

    No local Codex data or config had to be deleted.

  7. Fearlex-creator commented on Sep 28, 2026

    @Fearlex-creator
    Fearlex-creator
    on Sep 28, 2026 – with ChatGPT Codex Connector

    I’m seeing the same issue after upgrading the Codex desktop app: every new desktop chat stays on “Starting your task,” while Codex CLI still works.

  8. steven-d-pennington commented on Sep 28, 2026

    @steven-d-pennington
    steven-d-pennington
    on Sep 28, 2026

    Same issue here: Linux desktop 26.924.22138 (apt .deb, Pop!_OS / GNOME Wayland, x64, kernel 7.1.5), auto-updated from 26.917.51856.

    • Every new message hung at "Starting your task…". thread/start succeeded but turn/start was never sent.
    • The main ChatGPT process had a growing list of <defunct> children (bash, git, gh, ps, codex). SIGCHLD was caught and not blocked in /proc/<pid>/status, so the process just wasn't reaping them.
    • As a result, every startup logged Failed to load shell env ... Timed out after 5000ms and Git is unavailable, even though git --version finishes in ~4ms both directly and under codex sandbox.
    • The bundled engine works fine on its own: /usr/lib/chatgpt/resources/codex exec "..." answers in ~5s.

    Downgrading to 26.917.51856 fixed it (the .deb was still in /var/cache/apt/archives), then apt-mark hold chatgpt.

    In-app feedback ID: 01a0e730-0f4c-7123-9c06-59920907181f

  9. dehferion commented on Sep 28, 2026

    @dehferion
    dehferion
    on Sep 28, 2026

    Same issue.

    ChatGPT Linux GUI cannot start or resume local Codex tasks

    Environment

    • Ubuntu 24.04 LTS, Wayland.
    • ChatGPT desktop 26.924.22138, build 11645.
    • Bundled Codex: 0.158.0-alpha.2.1.
    • Working VS Code extension agent: 0.155.0-alpha.16.3.

    Reproduction

    1. Start ChatGPT normally.
    2. Create a new project and send a short greeting.
    3. The UI remains at “Starting your task” and produces no answer.
    4. Previously created GUI conversations also fail to continue.

    A session started in VS Code remains usable through the GUI. Logs show the GUI using the follower stream role for that session. Work in a regular browser works according to the user.

    Checks performed

    • Full app restart and sign out/sign in did not resolve the issue.
    • A separate temporary Electron user-data directory did not establish a fix; the successful conversation was the existing VS Code session.
    • Bash with the GUI process environment exits successfully in 0.031 seconds and locates Git.
    • Git 2.43.0 runs successfully outside the GUI.
    • The bundled app-server responds successfully to initialize, account/read and configRequirements/read. Workspace routing is present; requirements are empty in this independent test.
    • The bundled app-server successfully creates an ephemeral empty read-only thread in 0.701 seconds. No model turn was submitted.

    Observed failures

    • Startup reports “Failed to load shell env” after approximately 5000 ms.
    • Multiple exited bash, git, ps and codex children remain zombies under the main ChatGPT process across app restarts.
    • Sending SIGCHLD once to the exact main ChatGPT process did not reap those children or resolve the observed condition.
    • GUI reports “Git is unavailable”.
    • A thread_hydration span times out after 122812 ms. Recorded stages: writable_roots_ready at 69.2 ms and metadata_ready at 92 ms; no runtime_resume_started stage is recorded in that span.
    • Other logs, particularly around sign-out/sign-in, contain “Workspace routing is unavailable” (432) and “Desktop network policy does not allow this destination” (500).
    • Cloudflare challenges were observed on /ces/v1/rgstr and /ces/v1/projects/oai/settings. Their causal relationship to task startup is unconfirmed.

    Assessment

    Evidence points to a failure during desktop GUI preparation/coordination before runtime resume/start. Child-process completion handling is a strong candidate, but causality and the exact defective component have not been proven. Successful direct thread creation does not test full model generation or every GUI-specific tool.

    No app source, security policy, account settings, history, or main profile was modified. Temporary diagnostic app-server processes were terminated after the checks.

  10. yuzhu-oai commented on Sep 28, 2026

    @yuzhu-oai
    yuzhu-oai
    on Sep 28, 2026
    Contributor

    The issue has been fixed. Please update to the latest version.

  11. yuzhu-oai
    closed this as completedon Sep 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    LinuxappIssues related to the Codex desktop appbugSomething isn't workingsessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions