You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Hung checkpoint capture leaves multiple threads in the same workspace stuck #17825
Three threads in one workspace became stuck showing “Thinking” or “Compacting,” affecting both Codex and Claude.
Diagnosis
One Codex turn emitted turn/completed, but its checkpoint capture never finished. Two subsequent threads stalled during provider-turn.start.
The installed source serializes checkpoint operations by workspace. Starting an agent turn also captures a baseline checkpoint. A hung capture could therefore block subsequent turns across providers. This is a suspected explanation; the underlying Git hang is unconfirmed.
Steps to reproduce
No deterministic minimal reproduction established. Observed sequence:
Run several Codex and Claude threads against the same checkout.
A Codex turn finishes, but checkpoint capture remains running.
Subsequent threads stop progressing.
Restart the desktop app, then update and restart again.
The checkpoint is retried but remains blocked.
Version
Initially desktop 0.0.46-nightly.20261009.2861. Still affected after updating to 0.0.46-nightly.20261010.2922.
Environment
macOS arm64, OS build 25.6.0; desktop app with local backend. Triage CLI used Node 26.8.2.
Evidence
- Provider emitted `turn/completed` at `2026-10-10T12:25:09.188Z`.
- `checkpoint.capture` remained running from `12:25:09.248Z`.
- Two `provider-turn.start` operations remained running from approximately `13:07–13:08Z`.
- All three threads have the same checkpoint workspace.
- After restart, checkpoint attempt count became 2; after update, 3.
- Two live Git processes held separate temporary checkpoint index locks before the update.
- Read-only tracked Git status completed in approximately 0.1 seconds.
- Untracked-file enumeration exceeded a 5-second diagnostic timeout. Git LFS filters are configured; their involvement is unconfirmed.
Related issues
#6560 and #8618 concern stuck threads, but describe different triggers. No exact duplicate identified.
Fix applied or workaround
Restarted and updated the desktop app. Checkpoint capture remains blocked. No manual database edits or source patches performed.
Triage on Linux against main 70e5e384da could not reach a runtime reproduction: isolated worktree dependency setup stalled, followed by an execution-host timeout. This does not establish whether the reported macOS failure persists. Open-issue review found no exact duplicate describing later threads blocked across providers in the same checkout.
To reproduce the Git hang, please provide the latest affected version, the blocked Git command and its elapsed time, and sanitized checkpoint trace spans around the stall. Does it also occur in a small checkout without LFS or with untracked files excluded? A small repository or precise sequence that triggers the capture stall would let us distinguish slow file enumeration from a filter/process hang. Please omit credentials and private prompt contents.
Activity
juliusmarminge commentedon Oct 22, 2026
Triage on Linux against main 70e5e384da could not reach a runtime reproduction: isolated worktree dependency setup stalled, followed by an execution-host timeout. This does not establish whether the reported macOS failure persists. Open-issue review found no exact duplicate describing later threads blocked across providers in the same checkout.
To reproduce the Git hang, please provide the latest affected version, the blocked Git command and its elapsed time, and sanitized checkpoint trace spans around the stall. Does it also occur in a small checkout without LFS or with untracked files excluded? A small repository or precise sequence that triggers the capture stall would let us distinguish slow file enumeration from a filter/process hang. Please omit credentials and private prompt contents.