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

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.

1. Open an ordinary local task.
2. While its turn is active, invoke set_thread_archived({archived:true}) without a threadId, so the tool targets the calling task.
3. Observe that the task disappears from the ordinary task list and appears in the archived-task list.
4. Inspect the completed turn with read_thread.
5. Observe that the turn status is interrupted and the tool item is status:"failed", success:false, despite the successful archive mutation.
6. Restore the task from another task and repeat steps 1–5. The same result occurs.
7. 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

---

Copyright 2026 The MathWorks, Inc.

Start at the set_thread_archived task tool and the app-server thread/archive path, then inspect the logs_2.sqlite teardown event showing had_active_turn=true. Compare the active-task self-archive flow with the control case using an explicit threadId, and use state_5.sqlite plus the rollout JSONL to verify the mutation, tool result, and turn status. Done means those outcomes agree, with either a clean acknowledgement or a structured rejection before state changes.