[deep-report] push_repo_memory safe-output silently wipes the repo-memory working directory instead of validating it (data loss)

[github-actions]

Description

Calling the push_repo_memory safe-output tool mid-session — whose own description is "Validate repo-memory files are within configured size limits before the workflow [completes]" — silently deletes the entire repo-memory working directory from disk instead of just validating it, and reports success rather than an error.

Reproduced live during this DeepReport run:

1. Wrote new content to all 6 files under /tmp/gh-aw/repo-memory/default/deep-report/ (confirmed immediately after each write via wc -l — e.g. last_analysis_timestamp.md went from 137 to 152 lines).
2. Called safeoutputs push_repo_memory '{}' (and again with {"memory_id":"default"}). Both calls returned {"result":"success","message":"Storage validation passed: 0 file(s), 0 KB total content, 0 KB patch diff (0 bytes) ..."} — i.e. it reported zero files even though 6 freshly-written files existed moments earlier.
3. Immediately after, ls -la /tmp/gh-aw/repo-memory/default/deep-report/ showed an empty directory (just ./..), and git status inside /tmp/gh-aw/repo-memory/default/ (a git checkout of the memory/deep-report branch) showed every file — including 2 unrelated legacy-path copies under memory/deep-report/ and memory/default/ — staged as deleted, with the directory's own mtime matching the exact moment of the tool call.
4. The pre-wipe content was only recoverable because it had previously been committed to the memory/deep-report branch (git show HEAD:deep-report/<file> still had it); anything written and not yet committed upstream is lost with no warning.

Expected Impact

This is very likely the root cause of long-standing repo-memory staleness observed independently in this very deep-report memory folder: its own last_analysis_timestamp.md had not been updated since ~2026-09-07, despite the DeepReport workflow running continuously since then (confirmed via discussion history — a briefing ran just ~6.5h before this one). Per the project's own workflow instructions, every cycle is told to call push_repo_memory after writing memory files — if every one of those calls wipes the agent's own uncommitted writes before the post-workflow commit/push step runs, repo-memory silently stops accumulating for any workflow using this safe-output, with no error ever surfacing to the agent or a human.

Suggested Fix

push_repo_memory should validate the working directory's pending state (e.g. by diffing against a copy, or using git diff --staged/--stat without mutating the working tree) rather than performing any destructive git operation (checkout/reset/clean) directly on the directory the agent is actively writing to. At minimum, it should never report "0 files, success" when the directory is non-empty before the call and empty after — that specific combination should fail loudly instead.

Suggested Agent

An agent familiar with the safe-outputs runtime / repo-memory push implementation (see actions/setup/js/push_repo_memory.cjs and .github/skills/developer-internals/SKILL.md).

Estimated Effort

Medium (1-4 hours) — needs careful review of whatever runtime component backs the push_repo_memory MCP tool (likely distinct from the compile-time pkg/workflow/repo_memory*.go generators and the post-workflow actions/setup/js/push_repo_memory.cjs committer) to find where it touches the live working directory, plus a regression test asserting a validation call never deletes agent-written files.

Data Source

DeepReport analysis — reproduced directly in this run (see this cycle's flagged_items.md/known_patterns.md entries in the memory/deep-report repo-memory branch for full repro notes).

Generated by 🔬 Deep Report · claude · agent · 548.3 AIC · ⌖ 12.8 AIC · ⊞ 7.1K · ◷

• expires on Oct 5, 2026, 5:48 PM UTC-08:00