Issue Station
Sign In
Tools hereToolbox

gemini-cli - ✅(Solved) Fix Tighten private Auto Memory patch target allowlist [1 pull requests, 1 comments, 2 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#26520•Fetched 2026-05-06 06:35:53
View on GitHub
Comments
1
Participants
2
Timeline
8
Reactions
0
Author
SandyTao520SandyTao520
Participants
gemini-cli[bot]gemini-cli[bot]SandyTao520SandyTao520
Timeline (top)
labeled ×3cross-referenced ×2commented ×1parent_issue_added ×1

Fix Action

Fix / Workaround

Auto Memory's private memory patch allowlist is broader than the documented contract.

The code says private memory patches should target memory markdown files inside the project memory directory, but the implementation currently allows any path under config.storage.getProjectMemoryTempDir().

  • packages/core/src/commands/memory.ts
  • packages/core/src/services/memoryPatchUtils.ts

PR fix notes

PR #26535: Tighten private Auto Memory patch allowlist

Description (problem / solution / changelog)

Summary

Tightens Auto Memory private patch validation so private memory patches can only target the project memory document set: MEMORY.md and direct sibling markdown files in the project memory directory.

Details

Private memory patch listing, aggregate apply/dismiss, and direct apply now share a kind-aware target validator. The validator rejects in-root but non-memory targets such as extraction state files, locks, .inbox/, skills/, nested paths, and non-markdown files.

The shared parsed-patch applicator now accepts an optional resolved-target predicate so memory patches can narrow a coarse root allowlist without changing skill patch behavior.

Also tightened the global memory single-file contract so child paths under ~/.gemini/GEMINI.md/ are rejected.

Related Issues

Fixes #26520

How to Validate

Run:

npx vitest run packages/core/src/commands/memory.test.ts
npm run typecheck --workspace @google/gemini-cli-core
npx prettier --check packages/core/src/commands/memory.ts packages/core/src/services/memoryPatchUtils.ts packages/core/src/commands/memory.test.ts
npm run build --workspace @google/gemini-cli-core
npm run lint --workspace @google/gemini-cli-core
env RUN_EVALS=1 npx vitest run --config evals/vitest.config.ts evals/skill_extraction.eval.ts

Expected results:

  • Memory command tests pass.
  • Core typecheck, formatting, build, and lint pass.
  • skill_extraction.eval.ts reports 4 passed and 1 skipped. The skipped case is gated behind RUN_SCRATCHPAD_STATS=1.
  • Private patch attempts for .extraction-state.json, .extraction.lock, .inbox/*, skills/*, non-markdown files, and nested markdown paths are omitted from listing and rejected on direct apply.
  • Valid private patch flows for MEMORY.md and direct sibling *.md files still pass.

Pre-Merge Checklist

  • Updated relevant documentation and README (if needed)
  • Added/updated tests (if needed)
  • Noted breaking changes (if any)
  • Validated on required platforms/methods:
    • MacOS
      • npm run
      • npx
      • Docker
      • Podman
      • Seatbelt
    • Windows
      • npm run
      • npx
      • Docker
    • Linux
      • npm run
      • npx
      • Docker

Changed files

  • packages/core/src/commands/memory.test.ts (modified, +63/-0)
  • packages/core/src/commands/memory.ts (modified, +207/-22)
  • packages/core/src/services/memoryPatchUtils.ts (modified, +18/-4)
RAW_BUFFERClick to expand / collapse

Problem

Auto Memory's private memory patch allowlist is broader than the documented contract.

The code says private memory patches should target memory markdown files inside the project memory directory, but the implementation currently allows any path under config.storage.getProjectMemoryTempDir().

Relevant code:

  • packages/core/src/commands/memory.ts
  • packages/core/src/services/memoryPatchUtils.ts

The current flow is:

  1. getAllowedMemoryPatchRoots(config, 'private') returns the full project memory temp directory.
  2. resolveTargetWithinAllowedRoots() accepts any canonical path under that root.
  3. listInboxMemoryPatches() and applyInboxMemoryPatch() therefore accept private patch targets that are inside the memory temp directory but are not actual memory markdown files.

Impact

A private memory patch can target files that should not be part of the memory patch surface, including:

  • .extraction-state.json
  • .extraction.lock
  • .inbox/*
  • skills/*
  • arbitrary non-markdown files under the project memory temp directory

This weakens the review boundary and does not match the extraction prompt or comments around the private memory patch contract.

Expected Behavior

Private memory patches should only be able to target:

  • the private project memory index, MEMORY.md
  • approved sibling markdown files directly under the project memory directory

Private memory patches should reject:

  • .inbox/
  • skills/
  • extraction state and lock files
  • non-markdown files
  • nested paths that are not part of the private memory document set

Acceptance Criteria

  • Private memory patch validation rejects in-root but invalid targets.
  • Tests cover attempts to patch .extraction-state.json, .inbox/*, skills/*, and non-markdown files.
  • Existing valid flows for MEMORY.md and sibling *.md files still work.
  • The implementation and comments agree on the exact allowed private memory patch target set.

Notes

This is a safety tightening issue rather than a request to change the overall Auto Memory inbox model. The existing review-first design is good; the target allowlist just needs to be narrower.

extent analysis

TL;DR

Update the getAllowedMemoryPatchRoots function to return a more restrictive path, allowing only the project memory directory and its direct markdown files.

Guidance

  • Review the getAllowedMemoryPatchRoots function in packages/core/src/commands/memory.ts to ensure it returns the correct path.
  • Modify the resolveTargetWithinAllowedRoots function in packages/core/src/services/memoryPatchUtils.ts to reject targets that are not markdown files or are not directly under the project memory directory.
  • Add tests to cover attempts to patch invalid targets, such as .extraction-state.json, .inbox/*, skills/*, and non-markdown files.
  • Verify that existing valid flows for MEMORY.md and sibling *.md files still work after the changes.

Example

// Example of how to restrict the allowed roots to only markdown files
// in the project memory directory
function getAllowedMemoryPatchRoots(config, type) {
  if (type === 'private') {
    return path.join(config.storage.getProjectMemoryTempDir(), '*.md');
  }
  // ...
}

Notes

The changes should focus on tightening the safety of the private memory patch allowlist without altering the overall Auto Memory inbox model.

Recommendation

Apply a workaround by updating the getAllowedMemoryPatchRoots function to return a more restrictive path, as this will help to narrow down the allowed private memory patch target set and improve the security of the system.

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…
#runtime error#dependency conflict#environment setup#docker error#permission error

Still need to ship something?

×6

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

Back to top recommendations

TRENDING