# Bug report: Memory harness fails to auto-commit and auto-push Edit-tool changes

report.md

Letta Code version: 0.27.8 (macOS) / 0.27.9 (Railway worker) Severity: High — silent data loss for agent learnings

What I observed

On 2026-06-16, while making several Edit tool calls to memory block files in the agent's MemFS (for example reference/letta-code-remote-worker-integration.md and reference/team-learnings.md), the Letta memory harness did not auto-commit the changes. Running git status in the local Mac MemFS showed the modifications as unstaged, with 49 other recent commits also still unpushed to origin.

This means a multi-turn session that includes Edit-tool calls to memory blocks can leave the new learnings only in the working tree on the local machine. If the Mac restarts, the memfs resets, the harness re-clones from origin, or the user switches machines, those learnings are silently lost — even though the agent believes it has persisted them (the system prompt at the top of every conversation advertises an auto-commit/push workflow).

Steps to reproduce

1. Open a Letta Code conversation.
2. Use the Edit tool to modify a file under $MEMORY_DIR (typically ~/.letta/agents/<agent-id>/memory/...).
3. End the turn (or continue with further tool calls).
4. On the local Mac, run:

   cd ~/.letta/agents/<agent-id>/memory
   git status
   

5. Expected: the modifications are committed (or at least staged) and pushed to origin. The system prompt at the top of every conversation says the harness does this automatically:

   cd "$MEMORY_DIR"
   git add .
   git commit --author="$AGENT_NAME <$AGENT_ID@letta.com>" -m "<type>: <what changed>"
   git push

6. Actual: the modifications appear as unstaged changes. The harness has not committed them. git log origin/main..HEAD shows 49 prior unpushed commits (mostly auto-generated skill installs and reflection logs from earlier turns) ‚Äî and none of those include the new Edit-tool changes either.

Expected behavior

The harness should reliably auto-commit and auto-push memory edits — either:

• After each Edit tool call (immediate), or
• At end of each turn, or
• On a debounce (e.g., within 30s of the last memory edit)

Whatever the trigger, it must be reliable. The current behavior — where some auto-generated content (skill installs, reflection logs) IS committed but direct Edit-tool changes are NOT — is the worst of both worlds: the agent assumes its memory is durable, but only some of it actually is.

Workaround (what I had to do manually)

From the local Mac MemFS, after discovering the uncommitted changes:

cd ~/.letta/agents/<agent-id>/memory
git add reference/<edited-file>.md
git -c user.name="<Agent Name>" -c user.email="<agent-id>@letta.com" \
    commit -m "learn: <description of the edit>

Co-Authored-By: Letta Code <noreply@letta.com>"

Then push. The local Letta Desktop proxy at http://localhost:51051 is currently returning intermittent HTTP 500s for git operations, so the workaround is to bypass it and push directly to https://api.letta.com/v1/git/...:

# Verify what origin currently has
curl -s -u "any:$LETTA_API_KEY" \
  "https://api.letta.com/v1/git/<agent-id>/state.git/info/refs?service=git-upload-pack"

# Bypass the local proxy and push
git remote set-url origin "https://any:$LETTA_API_KEY@api.letta.com/v1/git/<agent-id>/state.git"
git push --force-with-lease=main:<origin-current-sha> origin main
git remote set-url origin http://localhost:51051/v1/git/<agent-id>/state.git

The force-with-lease=<expected-sha> is required because the server-side ref pointer can drift between when you last fetched and when you push, and a plain push is rejected with "fetch first" until the local cache refreshes.

Impact

1. Silent data loss of agent learnings. Edit-tool changes to memory blocks are not committed by the harness. If the local memfs is ever reset, the agent's accumulated knowledge — proto install gotchas, cron migration workflows, project conventions, team-delegate rosters, anything an agent has written into its memory — is gone. The agent has no way to detect this from inside a conversation; the system prompt at the top of the conversation still claims the memory is durable.

2. Skill-install and reflection-log commits are also un-pushed. In the same session, the harness DID commit (locally) 49 skill-install and reflection-log commits. None of them are on origin. A fresh clone from origin misses all of them. So both the aut