Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[ChatGPT Pro][GPT-6 Pro/Astra] Authorized execution repeatedly ends at acknowledgement before any tool call

Open
  • Is something wrong?
#52,356 1 comment 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
5/100
Issue type
Bug
Clarity
Needs clarification
Activity status
Active
Domain
ai-infra-agents

Research direction

The report describes ChatGPT web behavior rather than code in this repository, and it names no file, test or entry point to start from. Establishing the cause means reproducing the acknowledgement-then-stop turn pattern and separating model behaviour, tool orchestration and turn finalization, which is a maintainer-level investigation. Done would be a reproduction and a diagnosis, not a patch.

Written by the indexing model from the issue text.

Description

bug model-behavior

Summary

On 8 October 2026, a ChatGPT Pro project workflow using GPT-6 Pro / Astra repeatedly ended its turn immediately after acknowledging an already-authorized execution task and promising to start it.

The failure occurred before the first promised tool action: no visible retrieval, build, file edit, or browser QA followed. Sending another message produced another acknowledgement and another ended turn.

I previously posted this reproduction as a comment under #43882. I am opening a standalone report because the affected surface is ChatGPT and the task can stop before execution starts, rather than only after a progress checkpoint.

Original report: https://github.com/openai/codex/issues/43882#issuecomment-6059254235

Environment and scope

  • Product: ChatGPT, project workflow; not a Codex CLI session.
  • Subscription: ChatGPT Pro.
  • Model reported in the original reproduction: GPT-6 Pro / Astra.
  • Observation date: 8 October 2026.
  • Exact client/build and incident timestamps were not captured.

Task context

The request was a substantial website implementation and visual-parity task. It explicitly authorized retrieving project assets, modifying the build, running browser QA, fixing defects, saving checkpoints, packaging outputs, and finishing the review deployment.

The instructions explicitly required the assistant to:

  • start with tools in the same turn;
  • continue through implementation and QA;
  • avoid ending after a plan, acknowledgement, or promise to continue;
  • stop only on completion or a genuine blocker.

No missing approval or concrete blocker was surfaced in the acknowledgement-only turns.

Observed sequence

  1. An earlier attempt on the same project had failed before a valid persisted checkpoint and closeout.
  2. I started a fresh Pro attempt and asked it to perform the actual execution.
  3. It acknowledged the task and said it was starting.
  4. The turn ended without a visible tool call or build/file action.
  5. I pointed out that it had stopped and asked it to begin.
  6. It acknowledged the problem and again promised immediate execution.
  7. That turn also ended without the promised execution.
  8. A further recovery instruction was needed to repeat that tools must start in that same turn.

The visible pattern was:

Assistant promises to begin → turn ends → no execution → user asks again → assistant promises again → turn ends again.

The quoted sequence is a summary, not an exact transcript.

Expected behavior

For an authorized execution request, the assistant should perform the promised actions and continue until the requested work is complete or a concrete blocker is reached.

An acknowledgement or progress message should not itself be treated as completion of the requested task. If execution cannot start, the response should explain the actual blocker rather than imply that work is underway.

Impact

This repeatedly forces manual continuation or fresh attempts, consumes limited Pro usage, and makes long-running production tasks unreliable.

This is distinct from my report #52084, where the work completed but the client continued showing an active/disconnected turn. Here, the task stops before the promised execution begins.

Related reports

  • #43882 and my original comment linked above.
  • #27352 was referenced in the earlier report as a related premature-ending symptom.
  • My separate Windows ChatGPT desktop history/mode failure: #52355.

The observation does not establish whether the cause is model behavior, tool orchestration, or turn finalization. Please investigate the acknowledgement-to-execution transition and provide any known fix, mitigation, or ETA.

No private prompts, conversation identifiers, files, screenshots, or project materials are included.

Dominant language
Rust
Stars
130k
Forks
20.5k
Avg merge
1m
Merged PRs (30d)
998

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openai/codex

All issues in openai/codex

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.