Skip to content

ChatGPT Work on Linux: local task completes but desktop UI remains stuck on "Your task is being started" #48482

Closed
Closed
ChatGPT Work on Linux: local task completes but desktop UI remains stuck on "Your task is being started"#48482
Labels
LinuxappIssues related to the Codex desktop appapp-serverIssues involving app server protocol or interfacesbugSomething isn't working

Description

@jca60
jca60
opened on Sep 26, 2026

Summary

ChatGPT Work local execution in the Linux desktop app no longer synchronizes correctly with the desktop UI.

A local Work task remains indefinitely stuck at:

Your task is being started

However, the corresponding local Codex session actually ran successfully, accessed the local project, produced a final answer, and ended normally with task_complete.

Affected session

Session ID:

01a0d972-23be-7603-9844-764b66c9ff40

Local transcript:

~/.codex/sessions/2026/09/25/rollout-2026-09-25T18-42-11-01a0d972-23be-7603-9844-764b66c9ff40.jsonl

I already submitted this session through ChatGPT Desktop using / → Feedback → share existing session.

I am not attaching the complete transcript publicly because it contains information from my local project.

Environment

  • ChatGPT Desktop for Linux: 26.924.22138
  • AnduinOS 1.4.2 (Ubuntu-based)
  • X11
  • Shell: /bin/bash
  • Git: 2.51.0
  • Git executable: /usr/bin/git
  • Local project is an existing Git repository

I understand that AnduinOS is not currently one of the officially supported Linux preview distributions. However, the same ChatGPT Work workflow previously worked successfully on this installation and with the same repository.

Expected behavior

A local ChatGPT Work task should start normally and its progress and final answer should be displayed in the Work conversation.

Actual behavior

The desktop UI remains stuck at:

Your task is being started

No approval prompt is displayed.

The corresponding local Work/Codex execution nevertheless continues in the background and can complete normally.

The affected session ended with a normal task_complete event (duration_ms: 100166).

Desktop-side errors

Git works normally from the system terminal:

/usr/bin/git

git version 2.51.0

Shell startup was tested and is fast:

  • bash -l: approximately 0.041 s
  • bash -i: approximately 0.267 s

Both immediately find /usr/bin/git.

Nevertheless, ChatGPT Desktop logs:

Sep 26 14:23:21 chatgpt.desktop[4375]:
Failed to load shell env caller=startup
detail="Timed out after 5000ms."
durationMs=5026
path=/home/jca/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin
status=timed_out
timeoutMs=5000

Seconds later:

Sep 26 14:23:34 chatgpt.desktop[4375]:
[managed-worktree-archive-queue]
Worktree archive will be retried
errorMessage="Git is unavailable"
phase=queued

The Git is unavailable retry repeats periodically.

The problem is reproducible across application restarts. After a later restart with a different PID:

Sep 26 17:59:45 chatgpt.desktop[12894]:
Failed to load shell env caller=startup
detail="Timed out after 5000ms."
durationMs=5014
status=timed_out
timeoutMs=5000

followed by:

Sep 26 17:59:56 chatgpt.desktop[12894]:
[managed-worktree-archive-queue]
Worktree archive will be retried
errorMessage="Git is unavailable"
phase=queued

The PATH logged by ChatGPT itself contains both /usr/bin and /bin.

Additional observations

  • Work with the same account can start in the web version, but browser Work cannot access the local project.
  • Launching ChatGPT with --disable-gpu did not resolve the issue.
  • The same local Work workflow worked previously on this installation.
  • The shell environment timeout and Git is unavailable messages are present in journalctl, not in the Codex session log.

Reproduction

  1. Start ChatGPT Desktop on Linux.
  2. Open ChatGPT Work.
  3. Use Work locally with an existing local Git project.
  4. Start a Work task.
  5. The UI remains at Your task is being started.
  6. The corresponding local session nevertheless executes and can end with task_complete.

Please investigate the Linux desktop-side Work session attachment/state synchronization and shell environment/Git detection.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    app-serverIssues involving app server protocol or interfaces
    on Sep 26, 2026

  2. github-actions commented on Sep 26, 2026

    @github-actions
    github-actionsBot
    on Sep 26, 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. silasthegoldenwizard commented on Sep 26, 2026

    @silasthegoldenwizard
    silasthegoldenwizard
    on Sep 26, 2026

    I reproduced the same visible Desktop symptom on Debian 13 / X11 with ChatGPT Desktop 26.924.22138, but my controlled run appears to differ from the background-execution behavior described in this issue.

    In my test, the UI remained at “Starting your task” and eventually logged:

    name=turn_first_response_visible
outcome=failure
reason=timeout
responseRuntime=unknown
marksMs={"thread_creation_started":500.5,"thread_inputs_ready":627.4}
durationMs=161200.1

    A timestamp-based check of ~/.codex/sessions/*.jsonl did not find any file modified after submission, and I did not observe thread/start, turn/start, turn/started, or task_complete in the captured Desktop stdout/stderr.

    This does not prove that no backend execution occurred. However, unlike the reproduction documented here, I have not observed a corresponding background Codex session completing successfully.

    I posted the full diagnostics, methodology, and limitations in #48212.

    The two cases may still share the same root cause, but the observable failure stage appears different in my reproduction.

  4. jca60 commented on Sep 26, 2026

    @jca60
    jca60
    on Sep 26, 2026
    Author

    Thanks for the detailed Debian 13 reproduction and for documenting the difference.

    Yes, the observable failure stage in my case appears to be different.

    For session 01a0d972-23be-7603-9844-764b66c9ff40, I verified that a local session file was actually created under ~/.codex/sessions. The transcript shows successful local command execution against the project, a final answer, and finally a normal task_complete event (duration_ms: 100166).

    At the same time, the ChatGPT Desktop UI did not reflect that completed run correctly and remained stuck at “Your task is being started”.

    So we currently seem to have at least two variants of the same visible Linux Desktop symptom:

    1. Your Debian 13 reproduction: UI stuck, with no corresponding local Codex session observed starting/completing.
    2. My reproduction: UI stuck, while the corresponding local Codex session actually executes and reaches task_complete successfully.

    The fact that you reproduced the visible symptom on Debian 13 / X11 with the same Desktop version 26.924.22138 is also useful, since it suggests that my use of AnduinOS is unlikely to be the sole cause.

    I agree that the two variants may still share an underlying Desktop-side state/attachment problem.

    I’ll leave #48482 open for now because the confirmed background execution + task_complete behavior may provide an additional diagnostic path, unless a maintainer prefers to consolidate it into #48212.

  5. jca60 commented on Sep 27, 2026

    @jca60
    jca60
    on Sep 27, 2026
    Author

    One additional timeline detail that may be relevant:

    The problem did NOT first appear with ChatGPT Desktop 26.924.22138.

    I had already reproduced the same Work behavior with the immediately preceding Linux Desktop version, which I installed late Friday evening. I then updated to 26.924.22138 in an attempt to resolve the problem, but the issue persisted unchanged.

    So 26.924.22138 does not appear to be the version that introduced the problem; it is simply the current version on which I reproduced and collected the detailed diagnostics.

    I do not currently have the exact version number of the immediately preceding build, so I do not want to guess it.

  6. linear
    added
    Linux
    on Sep 27, 2026

  7. 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.

  8. 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 appapp-serverIssues involving app server protocol or interfacesbugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions