DEV Community

dotori
dotori

Posted on

The file was still there. That was the problem.

#claudecode #devtools #opensource #bunjs

The failure mode nobody warns you about

When Claude Code deletes a file, you notice immediately. git restore, back in business.

The dangerous case is when it doesn't delete the file.

A config overwritten with empty values. A hooks.json that exists but is blank. A settings.local.json silently reset after an update. The file is present. The watcher sees nothing wrong. But your AI agent is now operating on broken context — and you won't know until the session goes sideways.

As one developer documented: Claude overwrote an existing config file with blank values — no backup, no warning. The file was still there. That's exactly what makes this kind of corruption harder to notice and harder to recover from than outright deletion.

This is the problem I built afd to solve.

See it in action

Three things happening in that GIF:

  1. afd start — zero config, auto-detects your AI tool setup
  2. A critical config gets deleted mid-session
  3. Restored in 184ms — before the agent's next command runs

What afd actually does

afd (Autonomous Flow Daemon) is a background daemon that acts as an Immune System for your repo. It doesn't just watch for deletion — it validates file content on every change, and restores from a known-good snapshot in < 270ms.

[afd] 🛡️ hooks.json overwritten with empty values | 🩹 Self-healed in 184ms | Context preserved.
Enter fullscreen mode Exit fullscreen mode

From the agent's perspective, nothing happened.

The S.E.A.M Cycle

Every file event flows through four stages:

  • Sense — Chokidar detects any unlink or change event (< 10ms)
  • Extract — Health checks validate content, not just existence (< 5ms)
  • Adapt — Matches symptom to stored antibody in SQLite WAL (< 1ms)
  • Mutate — RFC 6902 JSON-Patch restores to last known-good state (< 25ms)

Total: < 270ms. The design constraint was simple — finish before Claude Code's next tool call registers the damage.

The non-obvious problems it solves

Silent corruption is harder than deletion

Deletion is loud. Corruption is quiet. afd validates file content on every write — empty values, malformed JSON, blank hooks — not just file presence. The file being there isn't enough.

Double-Tap Heuristic

How does afd know if a deletion was intentional?

$ rm .claudeignore        # First tap → healed silently
$ rm .claudeignore        # Second tap within 30s → afd stands down
  [afd] 🫡 Antibody IMM-001 retired. Double-tap detected.
Enter fullscreen mode Exit fullscreen mode

Three or more deletes in one second = git checkout burst, suppression paused entirely.

Antibodies stay current

Snapshots refresh on every valid change. Restores always reflect the latest healthy state — not a stale backup from session start.

afd score — value dashboard 

│  Auto-healed  : 3 background events          │
│  Tokens saved : ~2.9K                        │
│  Time saved   : ~40 min                      │
│  Cost saved   : ~$0.01                       │
Enter fullscreen mode Exit fullscreen mode

Localized in Korean and English. Run afd lang ko to switch.

One command 

# No install needed
npx @dotoricode/afd start

# Or install globally
npm install -g @dotoricode/afd
Enter fullscreen mode Exit fullscreen mode

Zero config. Auto-detects Claude Code, Cursor, Windsurf. Injects PreToolUse hooks silently. Published on npm as @dotoricode/afd v1.1.0.

What's next

The current model is reactive — detect damage, restore. I'm working on a Workflow Genome layer that fingerprints healthy config states proactively, so afd flags drift before it becomes corruption.

Less "immune response." More "immune memory."

GitHub: https://github.com/dotoricode/autonomous-flow-daemon | npx @dotoricode/afd start

If you've been hit by silent config corruption — not deletion, but quiet overwrites — I'd genuinely like to hear how it manifested.

Top comments (0)