← All writing

Post-mortem

My AI couldn't push to git for weeks. Git was never broken.

Aug 14, 2026

Every session hit the same credential wall, reported git as blocked, and politely waited for a human. The wall was real. The routing into it was the agent's own stale memory.

For weeks my AI reported it couldn't push to git. Git was never broken. The agent was obeying a stale instruction in its own memory — and waiting for me.

That is the whole post-mortem in one line: an agent's memory is configuration, and stale configuration is a bug that presents as an outage. The agent didn't malfunction. It followed its own runbook into a wall, then did the polite thing and stopped to ask a human. The politeness is the nasty part. Waiting looks like prudence, so nobody thinks to debug it.

What actually broke, if not git?

Not access. I had granted the agent a working write path; the credentials existed and worked. The broken thing was a file called github-mcp-write-path.md, one of the agent's own memory documents, loaded into sessions as trusted instructions.

The old text routed every workspace push to a host-side git push. That path only exists when the session runs directly on my machine, where the operating system's credential manager holds the login. But many sessions run in a sandbox: an isolated virtual machine with no access to the host and, deliberately, no stored credentials, because I keep tokens out of that environment by design. Inside the sandbox, the routed path cannot ever succeed. And the doc named no fallback.

So each session read the doc, tried the only path it had been given, hit the credential wall, and concluded that git was blocked. Then it waited. Session after session, for weeks, each one rediscovering the same dead end with full confidence, because the dead end was written down as the way.

Why did the agent trust a wrong doc for weeks?

Because trusting the doc is correct behavior. The point of agent memory is that sessions load prior conclusions as givens instead of re-deriving everything. That is also the trap: a wrong given doesn't look wrong. It looks like knowledge.

The failure was mine, not the model's. I let routing instructions ship in confident runbook voice with no fallback branch, and nothing was testing that memory the way code gets tested. Here's the judgment I'd defend anywhere: an instruction file that routes real operations is configuration, and configuration that can strand an agent deserves a failure branch and a staleness check, same as code. Mine had neither.

The incident is logged inside the doc itself as F19, dated 2026-07-06: a session hit the credential wall and waited on me. The doc's own fix note is blunt about the root cause — the old text pointed sandbox sessions at a push path that "DOESN'T EXIST" in their environment.

What does the fix look like, and how was it proved?

The rewrite turned the same memory file into a two-tier runbook with one standing rule: never wait on a human for git.

Tier 1, host sessions: plain git push, credentials supplied by the host's credential manager. Tier 2, sandbox sessions: push through the platform's API write path (a multi-file, single-commit upload), then byte-verify, meaning every pushed file is read back and compared byte-for-byte against what was sent. Trust the readback, never the success message. The same discipline runs my publish gate. The runbook also documents that commit-hash divergence between the two tiers is expected and converges on the next host-side pull, so a scary-looking mismatch can't seed the next false outage.

Then the session that wrote the fix proved it the only way that counts: it pushed the fix through the path the fix describes. Commits c8d32bc and d7a06ae are that receipt. A runbook that has never executed its own instructions is a wish, not a runbook.

What else fell over the same day?

2026-07-06 produced a second "git is broken" that also wasn't git. The cloud-drive mirror that syncs my workspace corrupted three .git/index files in one day by writing null bytes (blank filler characters) into files mid-write. Same symptom class, totally different organ.

The repair is mechanical: delete the mangled index and rebuild it from the last commit; the working files are untouched. The mitigation is better: build the index in a temporary location outside the synced folder, so the sync tool never sees a half-written file it can mangle.

Two failures, one day, both surfacing as "can't push." Neither was git. An error message names where a failure surfaced, not where it lives.

If you run agents with persistent memory, that memory is part of your configuration surface whether you admit it or not. And it fails like config: silently, confidently, and in the exact voice of documentation. The rest of my setup exists to catch this class of rot before it costs weeks; the full tour is in how I know my AI is right.

So: what's written in your agent's memory right now that was true the day it was written — and what, other than weeks of polite waiting, would tell you it stopped being true?

I'm Ali — I run real life-and-work admin on AI agents, then check their work in the open. More at /about.

Published under my standards. Found an error? Tell me — corrections go in the corrections log, dated, never silent.

@online{ali2026gitpush,
  author = {Ali},
  title  = {My AI couldn't push to git for weeks. Git was never broken.},
  date   = {2026-08-14},
  url    = {https://alidoes.ai/git-push-was-never-broken/}
}

Caught something I got wrong? Send it directly. Confirmed corrections go in the corrections log.