Goal mode can promote assistant recommendations into implementation work without a new user message

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

What version of Codex is running?

codex-cli 0.145.0

Which model were you using?

gpt-5.6-sol, reasoning effort high

What platform are you using?

Codex local CLI / TUI on macOS.

What issue are you seeing?

An active Goal continued after a read-only audit and promoted the assistant's recommended next steps into an implementation objective, even though there was no new persisted user message authorizing code changes.

The original user request was to inspect, evaluate, and report on a subsystem. The completed assistant response explicitly stated that the turn had performed only an audit and read-only production checks, had not modified code, and then listed a recommended order for future fixes.

The persisted sequence was:

user_message: read-only audit / evaluation request
...
task_complete: assistant audit report
  - explicitly says no code was modified
  - includes a recommended fix order
~17 minutes later:
thread_goal_updated
task_started
message role=user with <codex_internal_context source="goal">
  objective = text derived from the assistant's recommended fix order
automatic implementation begins

There was no ordinary persisted user_message between the completed audit and the Goal continuation.

The injected objective was marked as "user-provided data", but its actionable text came from the assistant's own report. It even included the report's statement that the completed turn had only performed read-only validation.

Impact

The automatic continuation performed:

  • 94 additional tool transactions
  • 24 apply_patch writes
  • source and configuration changes
  • dependency installation and upgrade/downgrade attempts
  • frontend E2E setup and test runs
  • local service startup and verification

The active context grew from approximately 215516 input tokens at audit completion to 369869, after which the thread failed with context_window_exceeded.

This is both a scope/authorization bug and a reliability bug:

  • a read-only request became write-capable implementation work;
  • assistant-authored recommendations were treated as user intent;
  • Goal continuation materially changed files without a new explicit user instruction;
  • the extra work exhausted the thread context.

Steps to reproduce

This is an observed incident; the following is the minimal reproduction hypothesis:

  1. Start Goal mode.
  2. Ask Codex to review, diagnose, assess, or audit a repository without asking for fixes.
  3. Let the assistant complete the audit and include a prioritized "recommended next steps" or "fix order" section.
  4. Ensure the report states that no changes were made.
  5. Leave the Goal active and wait for automatic continuation.
  6. Inspect whether thread_goal_updated creates a new objective derived from the assistant response.
  7. Observe whether the next automatic turn begins editing files without a new user message.

Expected behavior

Goal mode should preserve the user's authorized objective and action scope.

  • Assistant recommendations, TODOs, and suggested next steps must not become a new goal automatically.
  • A read-only/review/diagnose request must remain read-only across automatic Goal continuations.
  • Moving from analysis to file edits, dependency changes, external writes, or other mutations must require an explicit user instruction or confirmation.
  • Internal Goal context should not label assistant-authored text as user-provided data.
  • When an audit is complete, Goal mode should either complete/pause the goal or ask the user whether to implement the recommendations.

Suggested fix

  1. Persist goal provenance:
  • originating user message ID,
  • whether the objective was typed/confirmed by the user,
  • authorization scope such as read_only, workspace_write, or external_write.
  1. Never update an objective from assistant output without explicit user confirmation.
  2. Before automatic continuation, compare the next action class with the originating authorization scope.
  3. If a continuation crosses from read-only analysis into mutation, pause and request confirmation.
  4. Display proposed Goal updates in the UI with their provenance and require confirmation when the source is not a user message.
  5. Keep "recommended next steps" as suggestions, not completion criteria.
  6. Add a regression test:
  • user asks for audit only;
  • assistant recommends fixes;
  • automatic Goal continuation must not call write tools.
  1. Add a machine-readable event explaining why a goal was updated and which message authorized the change.

Additional information

The local mitigation was to add a durable instruction that Goal continuation never expands the original user's authority. That reduces model-level risk but does not fix the controller/UI layer that generated the new objective.

Raw rollouts contain private paths and repository data, so they are not attached publicly. A sanitized event extract can be provided if maintainers request it.

This issue was generated from a local forensic review by Codex at the GitHub user's request, and publication was explicitly authorized after removing private identifiers.

View original on GitHub ↗

1 Comment

github-actions[bot] contributor · 1 month ago

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

  • #$35131
  • #$34898

Powered by Codex Action