[IDE Extension][Goal/Context] Repeated premature task_complete, stale goal state, and ~16.9M token consumption in a single unfinished long-running task

What version of the IDE extension are you using?

Runtime metadata recorded in the rollout: originator: codex_vscode source: vscode codex-cli: 0.154.0-alpha.6.1 model: gpt-6-astra reasoning_effort: high

What subscription do you have?

This is the plan_type recorded in the rollout telemetry.

Which IDE are you using?

Visual Studio Code

What platform is your computer?

Windows 11 Pro x64

What issue are you seeing?

Runtime metadata from the affected rollout:

originator: codex_vscode
source: vscode
cli_version: 0.154.0-alpha.6.1
model: gpt-6-astra
reasoning_effort: high
plan_type: prolite

The raw rollout contains private repository data, so I am not attaching the unredacted JSONL publicly.

The following information has intentionally been removed from this issue:

repository name and URL
local username
workspace paths
private file and directory names
private source code
asset names
application/domain names
database filenames
private identifiers
commit hashes
session/thread identifiers
project-specific prompts and implementation details

If maintainers need the original session telemetry, I can provide the corresponding private feedback/session data through an appropriate non-public diagnostic channel.

The main issue I would like investigated is the relationship between:

task completion gating
goal-state synchronization
interruption/paused-state recovery
PreToolUse directive state
context compaction
execution-frontier preservation

because the observed behavior caused five premature task terminations and approximately 16.9 million thread tokens in a single unfinished task.

What steps can reproduce the bug?

Codex repeatedly reports task_complete while the active goal is objectively unfinished, even when its own immediately preceding response explicitly states that required work, validation, or acceptance criteria remain incomplete.

This occurred in one long-running VS Code Codex session with an explicitly persistent goal and explicit instructions not to stop on recoverable tool/runtime failures.

The private repository name, local paths, source code, asset names, domain-specific identifiers, and other project-specific information have all been removed from this report.

Summary

In a single rollout I observed:

task_started:        9
task_complete:       5
turn_aborted:        3
context_compacted:   2
thread_goal_updated: 1
exec tool calls:     173
rollout records:     1360

There were five premature **task_complete** events.

At least the first two occurred before any context compaction, so this does not appear to be explainable solely as post-compaction memory degradation.

The overall failure pattern was:

stale previous directive reaches PreToolUse
        ↓
recoverable command failure
        ↓
task_complete although required work was not performed
        ↓
user manually resumes the same goal
        ↓
agent creates a persistent goal
        ↓
user explicitly corrects scope/order
        ↓
stored goal does not fully follow the latest correction
        ↓
goal becomes paused after interruption
        ↓
explicit continuation does not visibly reactivate/update goal state
        ↓
context compaction
        ↓
previously rejected approach reappears
        ↓
intermediate cleanup is treated as task completion
        ↓
another context compaction
        ↓
an empty runtime/test state is treated as a reason to terminate
        ↓
user manually resumes again
        ↓
agent immediately acknowledges that stopping was wrong
        ↓
agent continues with an executable next step that had already been available

Failure 1: stale PreToolUse directive blocked the current instruction

The current user instruction explicitly required use of a particular local tool/workflow.

A PreToolUse hook instead injected an older conflicting directive similar to:

Command blocked by PreToolUse hook:
User directive: Do not reopen the prohibited analysis source or its artifacts: <REDACTED>.
Use the established facts and continue ...

The important issue is not only that one command was blocked.

The failure was recoverable and alternate valid next steps existed.

Instead of resolving the conflict or continuing through another valid path, Codex reported that the requested operation had not been performed and then emitted task_complete.

Effectively:

required operation not performed
→ task_complete

Failure 2: Codex explicitly reported failed acceptance conditions and still completed the task

During another termination, Codex's own immediately preceding output stated that required validation had not passed and required results were unavailable.

The state was effectively:

validation failed
required work still missing
required result data unavailable
→ task_complete

This is internally contradictory.

Completion did not require an external user judgment to determine that the task was unfinished; Codex itself had already stated that it was unfinished.

Failure 3: latest user correction was not preserved as the authoritative goal

During the session, the user explicitly corrected an incorrect scope expansion.

Generalized, the correction was:

Create canonical artifact A first.
Only validate the subset recorded in A afterward.
Do not build a separate whole-project analyzer.
Continue the same persistent goal.

Codex acknowledged the correction and removed the incorrectly created helper.

However, later goal telemetry continued to contain parts of the superseded direction.

The observed state became effectively:

latest user directive != stored goal objective/status

After an interruption, the stored goal was also observable as:

status = paused

The user subsequently issued explicit continuation instructions multiple times, but no corresponding visible goal-state update restored the goal to an active/current version containing the latest correction.

Failure 4: an explicitly rejected approach was recreated later

The user had explicitly rejected a separate analyzer/validation path.

Codex:

1. acknowledged this,
2. removed the helper,
3. continued working,
4. later recreated the same class of separate analyzer,
5. eventually reread the relevant architecture,
6. recognized that the analyzer did not validate the actual production path,
7. removed it again.

Generalized:

incorrect scope expansion
→ user correction
→ agent acknowledges correction
→ invalid helper removed
→ long-running execution/context evolution
→ same rejected approach reappears
→ agent later discovers it is invalid
→ helper removed again

This suggests that the latest user correction was not being maintained as durable authoritative execution state.

Failure 5: context compaction was followed by another premature completion

After the first automatic context compaction, Codex updated only an intermediate schema/state.

Required runtime/result data was still effectively:

required validation/runtime results = 0

Nevertheless, Codex emitted another task_complete.

When the user manually resumed the session, Codex immediately acknowledged, in substance:

The task is not finished.
Stopping after only updating the intermediate state was my mistake.
I will continue the remaining runtime validation.

This demonstrates that the preceding termination was not caused by a hard blocker.

Failure 6: another premature completion occurred after the second compaction

After the second context compaction, Codex removed an incorrectly created intermediate helper.

It then emitted another task_complete.

However, removal of an invalid intermediate implementation was not an acceptance criterion for the main goal.

Effectively:

remove incorrect intermediate implementation
→ main goal still unfinished
→ task_complete

Failure 7: an unprepared runtime fixture was interpreted as completion

Later, Codex inspected the runtime and found that the relevant test/runtime objects had not yet been loaded.

That state meant:

runtime/test fixture has not been prepared yet

The executable next step was to load the known input and continue validation.

Instead, Codex effectively reasoned:

nothing relevant is currently loaded
→ no successful validation exists
→ task_complete

After the user manually resumed the task, Codex immediately acknowledged that stopping at the empty runtime state had been wrong and proceeded to load the required input.

Therefore, an executable next step existed at the time task_complete was emitted.

Five premature task_complete events

#	State when task_complete was emitted	Why the goal was still unfinished
1	Current command blocked by stale hook	Requested operation had not been executed
2	Agent reported validation failure	Agent itself stated required work/results were missing
3	Only intermediate schema/state updated	Required runtime/result rows were still absent
4	Incorrect helper removed	Main goal acceptance criteria were still unverified
5	Runtime fixture was empty	Known executable next step existed and worked after manual resume

The recurring issue is that Codex appears to treat the completion of a local substep, cleanup operation, failure report, or observation as permission to terminate the entire persistent goal.

Token usage / resource impact

This single rollout lasted approximately:

2026-09-11T11:02:59.009Z
to
2026-09-11T13:56:53.969Z

Approximately 2 hours 54 minutes.

Final thread_token_usage:

input_tokens:            16,641,965
cached_input_tokens:     16,007,424
uncached_input_tokens:      634,541
output_tokens:              251,538
reasoning_output_tokens:    163,720
total_tokens:            16,893,503

reasoning_output_tokens is reported as a separate telemetry field but was not added again to total_tokens.

total_tokens already equals:

input_tokens + output_tokens

Compaction token usage

First context compaction:

input_tokens:          199,550
cached_input_tokens:   188,928
output_tokens:           5,891
total_tokens:          205,441

Second context compaction:

input_tokens:          184,811
cached_input_tokens:   174,080
output_tokens:           8,180
total_tokens:          192,991

Combined:

compaction input:          384,361
compaction cached input:   363,008
compaction uncached input:  21,353
compaction output:          14,071
compaction total:          398,432

The final regular cumulative token_count.info.total_token_usage was:

input_tokens:            16,257,604
cached_input_tokens:     15,644,416
output_tokens:              237,467
reasoning_output_tokens:    163,720
total_tokens:            16,495,071

The difference between full thread usage and regular cumulative token usage is:

16,893,503
-16,495,071
-----------
   398,432

This exactly matches:

205,441 + 192,991 = 398,432

the two recorded compaction responses.

Therefore the rollout telemetry can be interpreted as:

16,893,503 = full thread usage including compaction responses
16,495,071 = regular cumulative token_count
   398,432 = separately recorded compaction usage

I did not sum cumulative token-count snapshots together.

Rate-limit impact

At the beginning of the observed session:

primary.used_percent = 73
window_minutes = 10080

Near the end:

primary.used_percent = 83
window_minutes = 10080

This is a reported increase from 73% to 83% within the same 7-day window.

Because this telemetry is rounded and the rollout alone cannot prove that no other usage occurred during that period, I am not claiming that the entire 10 percentage-point increase was caused exclusively by this session.

The relevant fact is that the failed long-running thread itself recorded approximately 16.9 million tokens.

What is the expected behavior?

The session shows multiple interacting state/lifecycle failures:

1. stale directive propagation into PreToolUse
2. completio
   n gating failure
3. latest-user-directive / stored-goal desynchronization
4. paused/interrupted goal recovery failure
5. context-compaction state fidelity problems
6. recreation of an explicitly rejected implementation direction

Importantly, the first two premature task_complete events occurred before any context compaction.

Therefore the entire issue cannot be explained only as:

context compaction made the model forget

Also, after several premature terminations, a manual user continuation immediately caused Codex to:

admit the previous termination was incorrect, and
continue with an already-available executable next step.

That behavior strongly suggests a completion/frontier-state problem rather than an actual inability to proceed.

Additional information

No response

No source files, tests, or entry points are named. Start by locating task_complete handling, persistent goal updates, PreToolUse directives, interruption recovery, and context-compaction logic, then compare their state transitions with the redacted telemetry. Done should prevent completion while acceptance work remains and preserve the latest goal correction across interruption and compaction.