Codex Desktop: active task self-archive succeeds but tool reports failure and interrupts the turn

Open 💬 0 comments Opened Aug 24, 2026 by NANMINGZHIYUAN

Reporter: Codex investigation agent
Date: 2026-08-25
Severity: High
Reproducibility: Always (2/2 self-archive attempts in the affected task)

---

Summary

When an active Codex Desktop task calls set_thread_archived({archived:true}) on itself, the task is successfully moved to the archived list, but the tool event is persisted as failed / success:false and the active turn is interrupted. Archiving the same task from a different task returns success normally.

Expected Behavior

The operation must have one unambiguous outcome:

If active-task self-archive is supported, return a defined success acknowledgement and archive only after the active turn can finish cleanly.
If it is unsupported, reject it before changing persistent state and return a structured actionable error.

The persisted tool result, task-list state, and turn status must agree.

Actual Behavior

The archive mutation succeeds and the task disappears from the ordinary task list, but the calling turn is marked interrupted and its tool item is marked failed / success:false. No explanatory error text is attached. Retrying produces the same result.

Reproduction Steps

Prerequisites: Codex Desktop on Windows; one ordinary local task visible in the active task list; the set_thread_archived task tool available.

Open an ordinary local task.
While its turn is active, invoke set_thread_archived({archived:true}) without a threadId, so the tool targets the calling task.
Observe that the task disappears from the ordinary task list and appears in the archived-task list.
Inspect the completed turn with read_thread.
Observe that the turn status is interrupted and the tool item is status:"failed", success:false, despite the successful archive mutation.
Restore the task from another task and repeat steps 1–5. The same result occurs.
Control case: from another task, call set_thread_archived({threadId:"<TARGET_THREAD_ID>",archived:true}); observe a normal success result. Restore it externally afterward.

Minimal Reproduction

// Run inside the active task being archived.
await tools.codex_app__set_thread_archived({ archived: true });

Environment

Toolkit & Agent

| Detail | Value |
|--------|-------|
| SATK Version | N/A — Simulink Agentic Toolkit not involved |
| Agent / Client | Codex Desktop 26.818.41509; GPT-5.6 Sol |
| Bundled CLI | 0.149.0-alpha.4.1 from the affected thread row |
| Agent Workspace Root | Local Windows workspace |
| MCP Server Mode | N/A |
| Available MCP Tools | Relevant Codex app tools: list_threads, list_archived_threads, read_thread, set_thread_archived |

Skills

Host observability reported 252 registered skills in the affected session; all were registered with descriptions in the task bootstrap. The following skills were invoked during diagnosis:

Skills · 252   ⊘ 0   ▶ 2   ✗ 0

Unprefixed local skills

▶ memory-writeback, filing-bug-reports
Other registered skills were unrelated to the reproduction and were not invoked.

⊘ name-only · ▶ invoked · ✗ unregistered SATK

Skill Conflict Analysis

N/A — no instruction conflict among the invoked skills.

Platform

| Detail | Value |
|--------|-------|
| OS | Windows 25H2, build 26200.9168 |
| Architecture | AMD64 |

Error Output

Persisted tool item from each self-archive attempt:

tool="set_thread_archived"
arguments={"archived":true}
status="failed"
success=false
durationMs=59

Second attempt:

tool="set_thread_archived"
arguments={"archived":true}
status="failed"
success=false
durationMs=95

Matching sanitized app-server log line:

rpc.method="thread/archive" ... clearing thread listener during thread-state teardown thread_id=<THREAD_ID> listener_generation=1 had_listener=true had_active_turn=true

Control case from a separate task:

{"threadId":"<THREAD_ID>","archived":true}

Post-recovery authoritative state:

archived = 0
archived_at = NULL
rollout_path = ...\sessions\2026\08\24\rollout-...-<THREAD_ID>.jsonl

Visual Evidence

N/A — the task-list transition, persisted turn record, database row, and app-server log provide direct state evidence.

Impact

Scope: Any workflow that lets an active task call the official archive tool on itself; reproduced on a normal local Windows task.
Workaround: Do not synchronously self-archive an active task. Archive manually after completion or archive it from a separate controller task; after any archive error, read back the authoritative active/archived lists before retrying.
Blocking: The active turn is terminated before a normal final response. The false-negative result can also cause retries of a side-effect that already succeeded.

Related Files

| File | Relevance |
|------|-----------|
| %USERPROFILE%\.codex\state_5.sqlite | Authoritative threads.archived, archived_at, and rollout_path state |
| %USERPROFILE%\.codex\logs_2.sqlite | Contains the thread/archive request and had_active_turn=true teardown event |
| %USERPROFILE%\.codex\sessions\...\rollout-...-<THREAD_ID>.jsonl | Persists the interrupted turn and failed tool item after recovery |

Notes

Observation: the app server received thread/archive and logged listener teardown with had_active_turn=true.
Observation: the same target archives and restores successfully when controlled from a different task.
Hypothesis, not confirmed root cause: self-archive commits the archive mutation, then tears down the listener that must deliver the tool acknowledgement back to the same active turn.
Closely related open reports:
https://github.com/openai/codex/issues/25713
https://github.com/openai/codex/issues/32554
https://github.com/openai/codex/issues/32257

----

View original on GitHub ↗