Read the original article in Japanese
English adaptation of the Japanese article originally published April 10, 2026. The numbers below come from the author's past Codex session logs; they are not a general benchmark for AI agents.
Have you ever received a polished status report from Codex or Claude Code, only to discover that the task is still unfinished—and that the agent is waiting for another “continue” message?
I had this problem repeatedly. To understand it, I counted the exact Japanese prompt 「続けて」 (“continue”) in my historical Codex session logs. Then I changed the project's rules so an agent could report progress and continue low-risk work instead of treating every useful status update as the end of the task.
The goal was not unlimited autonomy. It was to distinguish unnecessary stops from decisions that genuinely require a human.
What the session logs showed
My Codex environment retained JSONL session logs. I extracted user messages consisting of exactly 「続けて」, rather than counting every sentence that happened to include that word.
The result was striking:
- 345 exact “continue” messages appeared in the checked logs.
- 341 of those messages came immediately after an assistant
final_answer. - That is 341 ÷ 345 ≈ 98.8% in this particular sample.
The count does not prove that every one of those 341 stops was unnecessary. It does show that my repeated prompts were strongly associated with the agent's final-answer boundary, rather than only with explicit approval requests or technical failures.
I initially suspected a weak model or an unclear prompt. The logs suggested another possibility: the agent often reached a good point to summarize, not a necessary point to stop working.
Different stops need different responses
It helps to classify the reason for a pause before adjusting the policy.
| Situation | What it means | Appropriate behavior |
|---|---|---|
A final_answer after a progress milestone |
The task may still have an obvious next step | Report and continue if allowed |
| Permission or approval is required | A human must authorize the action | Stop and ask |
| Alternatives carry meaningful trade-offs | The next step is not uniquely determined | Stop for a decision |
| A destructive change is imminent | An error could be costly | Stop at the safety boundary |
| A public post, send, or deployment is next | There is an external side effect | Require the applicable approval |
Formal closeout or /end is underway |
The session is being finalized | Follow closeout rules |
This distinction matters more than telling the agent to “never stop.” That instruction would erase the boundary between routine work and consequential actions.
The policy I adopted: report and continue
I changed the local guidance to make report and continue the default when all of the following are true:
- The next step is clear and has no meaningful competing alternative.
- The task is still within its authorized scope.
- The step is low risk and reversible.
- No approval, destructive operation, external publication, or formal closeout is pending.
When one of those conditions fails, the agent should stop and explain the specific blocker.
For example, reviewing another source file or running a permitted test may be an appropriate continuation. Merging a PR, publishing an article, or changing production credentials is not automatically authorized because the previous tests passed.
The policy is deliberately narrower than “finish everything without asking.”
Changes I made in the repository
To keep the behavior consistent across sessions, I recorded it in project files rather than relying on a one-off chat prompt.
My changes included:
analyze_continue_logs.pyto count the recurring prompt pattern.- Stop/continue conditions in
AGENTS.md. - A “do not wait for another 続けて when continuation is safe” rule in
codex-operator-guide.md. - A reusable
session-autocontinueskill. - Matching documentation in the README, handoff notes, and lessons learned.
These are names from my own repository at the time. They do not imply that Codex or Claude Code ships with a built-in feature using those filenames.
The reusable skill expressed the same idea through phrases such as keep going and stop only when blocked, while preserving the safety exceptions.
One short instruction became enough for many sessions:
Continue from the previous work. Keep proceeding until there is a concrete reason to stop.
That instruction only makes sense inside an existing permission and task contract. It cannot supersede approval gates.
When this approach helps
It is useful when you run coding agents repeatedly, preserve session logs, and manage tasks through repository-level instructions. It is especially relevant if you routinely find yourself repeating the same prompt after harmless progress milestones.
It is probably unnecessary for a one-time question or a short interaction without a continuing implementation task.
It can also make things worse if the agent cannot reliably identify its current task, next step, or authorization boundary. Uncontrolled continuation increases the risk of duplicate operations, scope drift, and expensive mistakes.
How to test it in your environment
Start with evidence, not a broad instruction change:
- Look for exact “continue,” “keep going,” or equivalent messages in your session logs.
- Record the action or event immediately before each one.
- Separate unnecessary final-answer stops from legitimate permission and decision boundaries.
- Add a concise local rule for low-risk continuation.
- Retest it on bounded tasks and watch for unintended actions.
My conclusion was specific: in my logs, most repeated “continue” messages followed final_answer; a repo-local stop policy helped address that pattern. It is not evidence that every coding agent should run continuously.
If you use an explicit closeout command such as /end, keep that separate from automatic continuation. That boundary can be used to capture lessons for future sessions rather than silently extending the current one.