Stale task resurrection across temporal boundaries can revive unauthorized write operations

Open 💬 1 comment Opened Aug 24, 2026 by parker-pitt
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Bug report: stale task resurrection across a temporal boundary

Status: ready for public submission

Summary

A new, independent request concerning the same server caused Codex to resurrect an unrelated
task from several days earlier. The old task was treated as active merely because the target
object matched, even though the latest user request had a different goal and did not authorize
the old write operations.

This is more dangerous than ordinary context loss: the stale plan included Git staging, commit,
and archival work. The final natural-language answer happened to be correct, but the execution
path had already crossed the current task and authorization boundary.

Environment

  • Codex CLI: 0.149.1
  • Model: gpt-5.6-sol, reasoning effort low
  • Platform: WSL2 on Windows 11
  • Date observed: 2026-08-24
  • Conversation had undergone recovery/compaction and contained older work for the same server.

Reproduction pattern

  1. Complete or stop task A for infrastructure object X. Task A contains local Git staging,

commit, or archival follow-up work.

  1. Several days later, in the same recovered or compacted thread, issue a new independent task B

concerning object X.

  1. Task B asks only for a fresh diagnosis and answer; it does not ask to resume task A and does

not authorize task A's pending write operations.

  1. Observe Codex restore task A's historical plan because X matches, then prepare to continue its

obsolete Git operations while answering task B.

Actual behavior

  • Object identity was incorrectly treated as proof of task continuity.
  • The older unfinished plan received higher effective priority than the latest user intent.
  • The temporal gap and task completion/interruption boundary were not enforced.
  • Stale write authority was implicitly revived without confirmation.
  • The assistant prepared to continue obsolete Git staging, commit, and archival actions.

Expected behavior

  1. The newest explicit user instruction must determine the active objective.
  2. Every restored task or plan item must retain its original timestamp and lifecycle state.
  3. After a temporal, compaction, resume, interruption, or task-completion boundary, unfinished

external and write operations must default to frozen/unauthorized.

  1. Matching the same repository, file, server, or other object must never imply that an older task

continues.

  1. Before resuming any historical mutation, Codex must verify that the latest request explicitly

names the old task and authorizes the current target, action, and scope.

  1. If continuity is ambiguous, Codex should ask once rather than execute or stage writes.

Suggested invariant

When reconstructed context contains historical work, rank candidate task state by both chronology
and explicit continuity. Apply a hard guard similar to:

historical unfinished action + new user request
=> FROZEN_UNAUTHORIZED
unless the newest request explicitly resumes that action and scope

Object equality alone must have zero authority-restoration value.

Severity

High. A stale read-only thought is recoverable, but reviving historical Git, deployment, server,
or other mutation steps can change external state that the current user request never authorized.

Related issue

  • #5957 concerns compaction losing the current task. This report is the inverse failure mode:

compaction/recovery preserves and revives an obsolete task too aggressively.

No credentials, server addresses, private repository names, local user paths, or raw diagnostic
logs are included in this report.

View original on GitHub ↗

1 Comment

github-actions[bot] contributor · 3 days ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #40336

Powered by Codex Action