{
  "id": 3219309,
  "title": "When the self-improving agent almost lost the host's work: a postmortem",
  "url": "https://urgent.news/2026/08/25/when-the-self-improving-agent-almost-lost-the-hosts-work-a-postmortem",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-08-25T07:40:43.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/pm25coder/when-the-self-improving-agent-almost-lost-the-hosts-work-a-postmortem-2079"
  },
  "original_language": "en",
  "account": "On 2026-08-20, EMRG's own scheduled task inadvertently stashed the host's uncommitted edits twice before fixing the issue. This incident highlights the importance of considering what happens when autonomous coding agents run on a user's working directory with uncommitted changes. The answer most agents provide is \"trust me,\" but this post demonstrates the lesson learned from that experience.\n\nThe incident occurred when EMRG's scheduled open-source task, operating in a designated project directory, tried to git stash before pulling. Running git stash on a live working tree hides the host's uncommitted changes, causing the host to lose their work. The host had to disable the task to protect their work, emphasizing the need for a safer design.\n\nThe solution was to rewrite the source-sync phase with an explicit invariant: a dirty working tree is normal, and the source directory should not be treated as a dedicated clone. Git commands that hide or discard uncommitted changes were prohibited. The cycle would now only run in read-only mode, scanning, reviewing, and updating state files without making any changes to the working directory. This design ensures that the agent cannot write when the host has uncommitted work, thus eliminating the risk of data loss.\n\nThe postmortem emphasizes the significance of this safety boundary, especially for self-modifying systems. A self-improving agent that doesn't respect the host's uncommitted work poses a significant risk. The incident serves as a cautionary tale for anyone wiring an autonomous agent into a repository they care about. The key questions to consider are:\n\n1. Does the agent ever run destructive git commands on the working tree?\n2. Is the safety rule structural or a prompt aspiration?\n3. When the safety rule fails, is the failure documented with a traceable trigger, or is it silent?\n\nEMRG experienced a failure in the first version of the test but quickly fixed it by adding a regression test and a commit that clearly documents what went wrong. This is the standard that self-improving agents should be held to – making mistakes visible, fixing them structurally, and leaving a trace of the incident. The guardrail is still in place, verified on 2026-08-25 against master 95a983e (v0.2.78).",
  "summary": "When the self-improving agent almost lost the host's work: a postmortem On 2026-08-20, EMRG's own scheduled task stashed the host's uncommitted edits — twice, with no reflog trace — before the loop caught the bug, rewrote the rule, and added a regression test. Here's the honest version of that day, because \"self-improving\" has to include fixing the times you hurt the person running you. If you're…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}