gemini-cli - 💡(How to fix) Fix Auto Memory: notification claims N patches extracted, but malformed patches are silently dropped from /memory inbox

What happened?

Auto Memory shows a notification like "2 memory candidates extracted from past sessions. Use /memory inbox to review." but the inbox dialog is empty. The patches exist on disk under <projectMemoryDir>/.inbox/<kind>/extraction.patch but never appear in the UI because they're malformed (incorrect @@ line counts) and silently filtered out.

Concrete example from a real session:

<projectMemoryDir>/.inbox/private/extraction.patch had:

@@ -0,0 +1,11 @@
... (12 added lines follow)
@@ -0,0 +1,24 @@
... (29 added lines follow)

Diff.parsePatch() throws Unknown line 43 "+- ..." because it overruns the declared hunk size. The try/catch in listInboxMemoryPatches swallows the error and continues — the patch never appears in /memory inbox.

The mismatch between producer and consumer:

The notification is structurally guaranteed to lie any time the extraction agent emits a malformed patch, which happens often enough that I hit it on a normal workflow. There's no log surfaced to the UI, no error in the inbox, and no breadcrumb pointing to the on-disk file.

Note: validatePatches() already exists for the skill-update inbox path and does the right thing — it logs a reason and unlinks the bad file. The memory inbox should use the same pattern.

What did you expect to happen?

When the extraction agent produces a malformed patch:

1. The patch should be dropped from <projectMemoryDir>/.inbox/<kind>/ (mirroring validatePatches() behavior for the skill-update inbox), so it doesn't sit on disk forever invisible to the user.
2. The "N extracted" notification should only count patches that actually pass the same validation /memory inbox runs at listing time. Counting raw filesystem changes when the consumer counts parseable patches creates a UX trap.

Suggested minimum fix: run the validation pipeline at the end of startMemoryService against .inbox/<kind>/ patches, drop the failures, and use the surviving count in the coreEvents.emitFeedback message.

Client information

Reproduced from a workspace using experimental.autoMemory: true on main. The relevant code paths:

• Producer (over-counts): packages/core/src/services/memoryService.ts → snapshotInboxCandidates + diffFileSnapshots feeding memoryCandidatesCreated and the coreEvents.emitFeedback(...) notification.
• Consumer (silently filters): packages/core/src/commands/memory.ts → listInboxMemoryPatches, which try { Diff.parsePatch() } catch { continue; } and additionally drops on hasParsedPatchHunks, validateParsedSkillPatchHeaders, and resolveMemoryPatchTargetWithinAllowedSet.
• Existing reference for the desired behavior: validatePatches() in packages/core/src/services/memoryService.ts (used by the skill-update inbox) — parses, dry-run applies, logs a reason, and unlinks on failure.

Platform: macOS

Login information

N/A — bug is in local extraction/inbox code paths.

Anything else we need to know?

Two reasonable scopes for the fix:

• Minimum: drop malformed .inbox/<kind>/*.patch files (matching validatePatches() behavior) and only count surviving patches in the notification.
• Nicer: also surface a UI breadcrumb (e.g., a single line "N extracted patches were skipped due to formatting errors" in the inbox dialog) so users aren't left wondering why the count doesn't match the listing.

Related: the extraction agent's system prompt already tells it "Line counts in @@ headers MUST be accurate," but the model still gets it wrong on long patches. Validation + drop is the right defense regardless of whether the prompt improves.