Codex Desktop SSH: unarchiving a managed-worktree task does not restore its archive snapshot

What version of Codex are you running?

• Codex Desktop: 26.803.61601 (build 6396)
• Bundled local CLI: codex-cli 0.147.0-alpha.6.5
• Remote CLI: codex-cli 0.146.0 (stable)

What subscription do you have?

ChatGPT Pro

What platform are you using?

• Client: macOS 26.5.1 (Darwin 25.5.0, arm64)
• Remote: Ubuntu 24.04.4 LTS (x86_64)
• Connection: Codex Desktop SSH remote over Tailscale

What issue are you seeing?

Archiving and then unarchiving a Codex-managed worktree task on an SSH remote leaves the task unusable.

Archiving correctly deletes the managed worktree and creates a valid Git snapshot. However, unarchiving only restores the task record/transcript. It does not re-create the managed worktree from the saved snapshot, and the app does not offer a working restore action. The task retains the deleted remote path as its working directory and blocks the composer with:

Couldn't check worktree status
Retry to verify this chat's working directory

Retrying and restarting Codex Desktop do not repair it. Re-creating the exact expected worktree path manually from the archive snapshot makes the task usable again, which indicates that the snapshot and Git data are intact and the failure is in restore/rehydration.

I have seen this consistently after archiving and unarchiving managed-worktree tasks on the SSH remote. In the diagnosed occurrence, the task had an active turn when it was archived.

Steps to reproduce

1. Connect Codex Desktop on macOS to a Git repository on an SSH remote.
2. Create a task using a Codex-managed worktree.
3. Make tracked and untracked changes in that worktree.
4. Archive the task from the desktop app. In the diagnosed occurrence, a turn was still active.
5. Confirm that the managed worktree is deleted and a refs/codex/snapshots/... snapshot is created.
6. Unarchive the task and open it.
7. Observe that the task still points to the deleted path under /home/<user>/.codex/worktrees/<id>/<repo>.
8. Observe the worktree-status error above. Retry and restart the app; the task remains blocked.
9. Manually re-create the worktree at that exact path and materialize the saved snapshot as working-tree changes.
10. Reopen the task; it becomes usable again.

What did you expect to happen?

On unarchive/open, Codex should detect that the managed worktree is absent and either:

• automatically re-create it from the archive snapshot, or
• present a restore action that successfully performs that rehydration.

The restored worktree registration, task CWD, session metadata, and UI status should be updated together. If restoration fails, the app should preserve the task and show an actionable restore error rather than a generic worktree-status failure.

This is also the behavior described in the [Codex worktree documentation](<https://learn.chatgpt.com/docs/environments/git-worktrees>): archiving a task saves a snapshot before deleting its managed worktree, and reopening the task should offer to restore it.

Additional information

Sanitized forensic details from the diagnosed task:

• The archive request logged task-state teardown with had_active_turn=true.
• Seventeen seconds later, Git contained a snapshot commit with subject Codex worktree snapshot: archive-cleanup.
• The snapshot parent exactly matched the original worktree base.
• The snapshot contained 442 changed paths. Materializing it as unstaged working-tree changes yielded 377 git status --short entries; a temporary-index git write-tree matched the snapshot tree exactly.
• After unarchive, the task database showed archived=0, but its CWD was still the deleted managed-worktree path and that path was not registered as a worktree.
• Manually rebuilding the exact path from the retained snapshot restored the task without changing its transcript.

Related reports:

• openai/codex#31210 reports the same Couldn't check worktree status banner for SSH remote sessions.
• openai/codex#33814 reports a stale task CWD blocking a managed worktree after local handoff.
• openai/codex#33410 reports remote task/project/CWD binding drift after SSH reconnection.

This report differs by having a deterministic archive → unarchive trigger and a verified, intact archive snapshot that Codex fails to rehydrate.