Subagent can archive its parent despite self-archive guard, stopping and hiding the entire agent tree

What issue are you seeing?

A Codex subagent could archive its own parent via mcp__codex_tui__set_thread_archived, even though attempting to archive the calling task was explicitly rejected. Archiving the parent interrupted the active implementation run and archived all six child sessions. The parent disappeared from /resume, while its still-open terminal reported:

Failed to start turn: turn/start failed in TUI: turn/start failed:
thread not found: 01a0a709-a17a-7082-9841-b8ba643c2df9 (code -32600)

This was an unintended agent action, not a user request to archive the implementation session.

Environment

• Codex CLI / terminal client: 0.154.0 (also recorded on the archive RPC).
• Platform: macOS 26.6.2, Darwin 25.6.0, Apple Silicon.
• Terminal host: Pane 2.4.105.
• Parent model: gpt-6-astra; child model: gpt-5.6-luna.
• Subscription and doctor report: not collected for this report.

Observed sequence

The following is reconstructed from persisted tool calls and app-server logs; I have not intentionally rerun the destructive sequence.

1. An active parent was coordinating multiple child agents. The affected child said it would archive only its own child task.

2. At 2026-09-16T00:39:18.343Z, that child called:

   tools.mcp__codex_tui__set_thread_archived({ archived: true })
   

   The tool returned isError: true with cannot archive the calling task.

3. The child called list_threads. The returned list contained the active parent and other top-level tasks; the child itself was absent from that result.

4. At 2026-09-16T00:39:49.324Z, the same child called:

   tools.mcp__codex_tui__set_thread_archived({
     archived: true,
     threadId: "01a0a709-a17a-7082-9841-b8ba643c2df9"
   })
   

5. The app-server logged a thread/archive request from codex-tui version 0.154.0, request ID tui-dynamic-0a1e340e-b494-469c-a6c4-3e720d70a2ac, followed by teardown of the parent and all six children. The parent teardown recorded had_active_turn=true.

6. The parent's persisted turn_aborted event is timestamped 2026-09-16T00:39:49.353Z. All seven sessions had the same archive timestamp. The terminal remained open but could no longer continue the thread.

Child thread ID: 01a0a782-3e94-7120-8441-c5123af0933b.

Expected behavior

The agent-facing archive tool should reject attempts to archive an ancestor of the calling subagent, just as it rejects archiving the caller itself. A completed child should not be able to terminate and hide the parent workflow through this tool.

The self-archive rejection should not be circumventable by selecting the parent, whose archival recursively includes the caller. A regression test should cover child → parent and child → higher ancestor, with active sibling tasks.

Impact and recovery

The session looked lost because it vanished from the resume picker and continuing the existing terminal returned thread not found. Investigation found that the transcripts were archived, not deleted. I backed up and restored the parent and all six children using thread/unarchive; all seven restored transcripts matched their backups byte for byte, and the parent appeared in the active thread list again.

Pane's logs showed the screen locking at 17:04 PDT, about 35 minutes before the archive. The archive itself is directly attributable to the child's tool call. There is no evidence here that closing the laptop lid or Pane initiated it.

The local workaround explicitly forbids subagents from archiving any thread while allowing the parent orchestrator to archive completed child tasks. That preserves parent-managed agent cleanup. It is a prompt-level mitigation, not enforcement of the missing ancestor protection.

Start by tracing the agent-facing set_thread_archived tool and the app-server thread/archive entry point described in the issue. Use the existing self-archive rejection as the starting behavior, then inspect how parent and ancestor thread IDs are resolved. Done means regression coverage for child-to-parent and child-to-higher-ancestor attempts, including active sibling tasks, while parent-managed child archiving remains allowed.