Resumed sessions repeatedly stop after partial execution and require manual continue prompts

[o4woto]

Update: still reproducible in 0.53.0

This is an unexpected failure in the --resume execution path, not a feature request or a general model-quality report.

• Reproduced on Gemini CLI 0.47.0 and 0.49.0.
• The task starts normally after resuming but stops before completion.
• No quota, context-window, or execution error is displayed.
• Entering continue resumes the same task temporarily, after which it may stop again.
• New sessions do not exhibit the same behavior as frequently.
• The issue occurs more frequently during long-running, multi-step coding tasks that require analyzing or modifying a large codebase and involve multiple tool executions.
• The separate session-file persistence and data-loss bug is tracked in [Bug]: Latest chat session permanently lost from /chat list after using gemini --resume #27368.

Expected behavior: A resumed session should continue executing the requested task until completion, or display an actionable error explaining why execution stopped.

---

What happened?

When I resume an existing Gemini CLI session and ask it to continue the previous task, the model starts processing but frequently stops responding midway.

The issue appears as if reasoning or tool execution has been interrupted. No final response or explicit error message is displayed, and the session does not continue unless I terminate or restart the CLI.

This happens repeatedly with resumed sessions. New sessions appear to work more reliably.

Steps to reproduce

1. Start Gemini CLI in a project directory.
2. Work on a long-running, multi-step coding task that requires analyzing or modifying a large codebase and involves multiple tool executions.
3. Exit Gemini CLI.
4. Resume the session using:

   gemini --resume <UUID>

5. Ask the model to continue the previous task.
6. Processing begins but may stop before producing a final response.

Actual behavior

• The session is restored successfully.
• Reasoning or tool execution begins.
• The response stops midway without completion.
• No actionable error, quota warning, or context-limit message is shown.

Screenshot

What did you expect to happen?

The resumed session should restore the previous conversation context and complete the requested task normally.

If the session cannot continue because of a context-window, quota, session-size, or turn limit, Gemini CLI should display a clear error or status message with a recommended recovery action instead of silently stopping.

Client information

Client Information

• Gemini CLI version: 0.47.0
• Operating system: macOS 26.5.1 (Build 25F80)
• Architecture: Apple Silicon
• Node.js version: v26.3.0
• Gemini CLI path: /opt/homebrew/bin/gemini
• Subscription: Gemini Code Assist Standard
• Account type: Organization account

The email address from /about has been intentionally omitted.

Login information

Google Sign-In using an organization account with a Gemini Code Assist Standard license. I am not intentionally using a Gemini API key or Vertex AI authentication for this workflow.

Anything else we need to know?

Frequency

The issue occurs repeatedly with resumed sessions, but not on every attempt.

Additional observations

• It is more noticeable in longer sessions with multiple tool executions.
• Starting a new session often avoids the problem.
• The session is resumed from the same project directory.
• No explicit quota, context-window, or session-limit error is displayed.
• The behavior appears related to restored session context rather than the original task.

This issue is also reproduced in 0.50.0...

This issue is also reproduced in 0.51.0... This issue is also reproduced in 0.52.0... This issue is also reproduced in 0.53.0...

[o4woto]

I found an additional reproducible inconsistency between the expected behavior of gemini --resume <UUID> and the chat files that Gemini CLI actually writes.

Observed behavior

1. Before resuming, the original chat file was:

   session-2026-06-22T13-46-f74ed4b6.jsonl — 128,894 bytes

2. Running gemini --resume <UUID> created a new chat file:

   session-2026-06-22T13-49-f74ed4b6.jsonl — 993 bytes

3. The new file contained only the initial session metadata and <session_context> message. It did not receive the resumed agent conversation.

4. When the agent produced a response, Gemini CLI continued writing the response to the original 13-46 file instead of the newly created 13-49 file. The file sizes changed as follows:

   • Original file: 128,894 → 298,862 → 432,112 → 436,915 bytes
   • Newly created file: remained at 993 bytes

5. After producing part of the requested work, the agent stopped instead of continuing the task. If I entered continue, the agent resumed for another segment, wrote again to the original file, and then stopped again. This cycle repeated.

Expected behavior

I am not certain whether a resumed session is intended to keep appending to the original chat file or migrate the conversation into the newly created file. Either behavior could be valid if implemented consistently. However, creating a new file while continuing to write all actual work to the old file is unexpected and difficult to understand.

At minimum, Gemini CLI should do one of the following:

• resume directly in the original chat file without creating an unused new file; or
• create a new resumed-session file and write the resumed conversation to that file consistently.

The agent should also continue executing the resumed task normally rather than stopping after every response and requiring repeated continue prompts.

The file-target inconsistency may be related to the execution state being lost or disconnected after each resumed response. Please review both the chat persistence target selection and the agent continuation state in the --resume path.

[o4woto]

Critical follow-up: --list-sessions can trigger deletion of both chat files

After the inconsistent --resume state described above, running:

gemini --list-sessions

caused all chat files for that resumed session to be deleted, including the large original file containing the actual conversation. This turns the resume issue into a potential data-loss bug.

State before deletion

Both files shared the same eight-character session suffix:

• Original file: session-2026-06-22T13-46-f74ed4b6.jsonl — contained the actual resumed conversation and continued growing
• New file created by --resume: session-2026-06-22T13-49-f74ed4b6.jsonl — remained at 993 bytes and contained only initial session metadata/context

After gemini --list-sessions, both files were removed.

Analysis of the Gemini CLI 0.47.0 code path

The deletion does not appear to be an intentional behavior of the list command itself. Automatic session cleanup runs during CLI startup before the --list-sessions handler.

The observed deletion is consistent with the following cleanup path:

1. The newly created 993-byte file has no resumable user conversation, so session parsing returns it as an invalid/non-resumable session.
2. Automatic retention cleanup unconditionally adds entries with no valid session information to the deletion list.
3. Cleanup derives the eight-character ID suffix from the invalid file name.
4. It then finds every chat file with the same suffix, including the valid original session file.
5. Because the list command's current process session ID does not match those stored sessions, all matching files are deleted.

Automatic session cleanup is enabled by default, so --list-sessions merely exposed the problem; another Gemini CLI startup may also trigger the same cleanup.

Expected behavior

• --list-sessions should be read-only and must never delete session history.
• A newly created empty/stub resume file should not cause a valid session file sharing the same short ID to be deleted.
• Cleanup should validate and delete files individually using the full session ID, not cascade deletion based only on an eight-character filename suffix.
• Invalid session files should be reported or skipped safely instead of silently causing related history loss.

No local username, absolute path, full UUID, or project hash is included in this report.

[o4woto]

I retested this after updating to Gemini CLI 0.49.0, and both problems are still reproducible:

• When I resume an existing session and ask it to continue the previous task, the session still stops partway through the work and requires another prompt to continue.
• Resuming still creates an additional session file, while the actual resumed conversation continues to be written to the original file.

So the behavior reported above has not been resolved in 0.49.0.

Also, could you clarify why this issue is still not categorized as a bug? It is currently marked only as status/need-triage and area/agent, with no issue type, even though the behavior is reproducible and includes both interrupted session continuation and inconsistent session-file handling.

[o4woto]

Follow-up to separate the two behaviors reported here:

• The session-file persistence and data-loss issue (--resume creating another JSONL file with the same short ID, continuing to write to the original file, and cleanup potentially deleting valid history) is already tracked in [Bug]: Latest chat session permanently lost from /chat list after using gemini --resume #27368.
• I have added a new confirmation there that the duplicate-file and incorrect write-target behavior is still reproducible on Gemini CLI 0.49.0.
• This issue (Resumed sessions repeatedly stop after partial execution and require manual continue prompts #28036) should remain focused on the separate behavior where a resumed task stops partway through execution and requires repeated continue prompts.

The two symptoms both occur through the resume path and may still be related internally, but the deterministic persistence/data-loss bug now has its existing dedicated tracking issue.

[tmtd4c93aac]

Hey just found your issue while looking for a different one. What you describe sounds exactly like #28351, they attempted to fix it in #28566, it should now looks like a proper error.

The root of the issue is the model itself, more likely to happen with larger context window which is why you might have seen it more often when resuming but it's unrelated to resuming itself.

They messed up the retries however so I raised a new ticket #28909