Issue Station
Sign In
Tools hereToolbox

gemini-cli - ✅(Solved) Fix `/clear` command fails to update plan/task directories for the new session [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
google-gemini/gemini-cli#25500•Fetched 2026-04-16 07:05:33
View on GitHub
Comments
0
Participants
1
Timeline
10
Reactions
0
Author
ruomengzruomengz
Participants
ruomengzruomengz
Timeline (top)
labeled ×3parent_issue_added ×2added_to_project_v2 ×1cross-referenced ×1

Root Cause

Summary: Executing the /clear command in Gemini CLI resets the conversation and generates a new session ID. While the Config object is updated with this new ID, the internal Storage instance remains tied to the initial session ID because it is set at construction and cannot be modified. As a result, the agent's system prompt and planning/tracking tools continue to use the file paths from the previous session, leading to "Plan Mode" pointing to the wrong directory.

PR fix notes

PR #25515: fix(cli): reset plan session state on /clear

Description (problem / solution / changelog)

Fixes #25500

Summary

/clear was only rotating the session ID on Config, while several pieces of session-scoped planning state continued to point at the previous session.

This change makes /clear start a true new planning session by resetting the approved plan pointer and rebinding session-scoped services and paths.

What changed

  • Added Storage.setSessionId(...) so session-scoped temp paths can move with the active session.
  • Updated Config.setSessionId(...) to:
    • update Storage
    • reset the cached TrackerService
    • refresh session-scoped plans directory registration when storage is initialized
  • Added Config.resetNewSessionState(...) for brand-new session resets.
  • Updated /clear to call resetNewSessionState(...) instead of only rotating the session ID.
  • Added regression coverage for:
    • storage session path updates
    • config session-scoped service/path updates
    • clearing approved plan state on new session reset
    • /clear calling the new session reset path

Why

Before this change, /clear created a new session ID but could still retain old plan-mode state:

  • /plan could still show the previously approved plan
  • tracker state could remain bound to the old session directory
  • session-scoped plan/tracker/task paths could stay stale

Validation

Passed:

  • npm run build --workspace @google/gemini-cli-core
  • npm run build --workspace @google/gemini-cli
  • npm run typecheck --workspace @google/gemini-cli-core
  • npm run typecheck --workspace @google/gemini-cli
  • npm run lint --workspace @google/gemini-cli-core
  • npm run lint --workspace @google/gemini-cli
  • npm run test --workspace @google/gemini-cli-core -- src/config/storage.test.ts src/config/config.test.ts
  • npm run test --workspace @google/gemini-cli-core -- src/tools/trackerTools.test.ts src/routing/strategies/approvalModeStrategy.test.ts src/prompts/promptProvider.test.ts
  • npm run test --workspace @google/gemini-cli -- src/ui/commands/clearCommand.test.ts src/ui/commands/planCommand.test.ts
  • npm run test --workspace @google/gemini-cli -- src/ui/hooks/useSessionBrowser.test.ts

Manual repro also passed:

  1. Create and approve a plan
  2. Confirm /plan shows it
  3. Run /clear
  4. Confirm /plan no longer shows the old approved plan
  5. Confirm /plan copy reports that no approved plan exists
<img width="689" height="350" alt="image" src="https://github.com/user-attachments/assets/25ad0086-f6ac-4f81-99b5-7cb4cbd7459e" /> (screenshot of the /plan and /plan copy commands after doing /clear on an already-approved plan)

Changed files

  • packages/cli/src/test-utils/mockConfig.ts (modified, +1/-0)
  • packages/cli/src/ui/commands/clearCommand.test.ts (modified, +4/-1)
  • packages/cli/src/ui/commands/clearCommand.ts (modified, +1/-1)
  • packages/core/src/config/config.test.ts (modified, +89/-0)
  • packages/core/src/config/config.ts (modified, +46/-0)
  • packages/core/src/config/storage.test.ts (modified, +21/-0)
  • packages/core/src/config/storage.ts (modified, +9/-1)
RAW_BUFFERClick to expand / collapse

Summary: Executing the /clear command in Gemini CLI resets the conversation and generates a new session ID. While the Config object is updated with this new ID, the internal Storage instance remains tied to the initial session ID because it is set at construction and cannot be modified. As a result, the agent's system prompt and planning/tracking tools continue to use the file paths from the previous session, leading to "Plan Mode" pointing to the wrong directory.

Steps to Reproduce:

  1. Start a session and enter Plan Mode.
  2. Create a plan and approve.
  3. Run /clear.
  4. Enter plan mode.
  5. Observed Behavior: It is showing approved plan from step 2.
  6. Expected Behavior: It is a new session, there should be no approved plan.

extent analysis

TL;DR

Update the Storage instance to use the new session ID after the /clear command is executed.

Guidance

  • The issue is caused by the Storage instance being tied to the initial session ID, which is not updated after the /clear command.
  • To fix this, the Storage instance should be updated to use the new session ID, potentially by adding a method to update the session ID or by recreating the Storage instance with the new ID.
  • Verify the fix by checking if the agent's system prompt and planning/tracking tools point to the correct directory after running the /clear command.
  • Consider adding a test case to ensure the Storage instance is properly updated after the /clear command.

Example

// Pseudocode example of updating the Storage instance
class Storage {
  constructor(sessionId) {
    this.sessionId = sessionId;
  }

  updateSessionId(newSessionId) {
    this.sessionId = newSessionId;
  }
}

// After /clear command
const newSessionId = generateNewSessionId();
storage.updateSessionId(newSessionId);

Notes

The exact implementation details may vary depending on the specific codebase and requirements. This solution assumes that the Storage instance can be updated or recreated with the new session ID.

Recommendation

Apply workaround: Update the Storage instance to use the new session ID after the /clear command is executed, as this is the most direct way to address the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#serialization error#model compatibility#GPU setup#container setup#orchestration issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING