Not the files — those are fine. The connections rot. You capture a note at 11pm and never link it to anything, so it becomes an orphan floating off the graph. A project note’s one-line summary describes what the project was three weeks ago. Two notes are obviously about the same thing and neither knows the other exists. Do this for a few months and you don’t have a second brain, you have a junk drawer with good search.

The honest fix is to weed the garden regularly. The honest truth is that nobody does, including me.

So I stopped relying on myself and built a gardener.

What it actually does

Every night at 3am, on my homelab box, a script runs:

1. Detect — exo garden, a plain query over the index, produces a report: here are the orphans, here are notes that should probably link to each other, here are summaries that look stale. No AI in this step. It’s SQL and graph traversal. Deterministic, boring, trustworthy.
2. Decide and write — that report gets piped to claude -p (Claude Code in headless mode). Claude reads the vault’s operating contract, makes only high-confidence edits — add a [[wikilink]] between two genuinely related notes, refresh a stale summary — caps itself at ~10 notes a night, and writes a dated log note explaining exactly what it changed and what it deliberately skipped.
3. Commit — the wrapper reindexes and lands everything as a single garden: 2026-06-09 … git commit, then pushes. My 3D graph viewer picks it up on the next sync.

The first real run, it found one orphan (90-meta/README), linked it into the notes it actually indexes, and then — this is the part I liked — declined to touch the 12 “stale summary” candidates because, on inspection, every one of them was already accurate. It wrote: “flagged by length, not staleness; churning them would add noise.” A gardener that knows when not to prune is the one you can leave alone.

“Isn’t this a solved problem?”

Mostly, no — but partly, yes, and I want to be straight about it. AI-assisted note-linking exists: Obsidian plugins like Smart Connections suggest related notes, and apps like Mem and Reflect auto-organize as you write. They’re good.

Three things make this different enough to build:

• Every change is a reviewable git diff, authored by a named agent. Not silent magic that rearranges your notes while you’re not looking. git log -p shows you exactly what the gardener did last night; git revert undoes a bad night in one command. For something as personal as a knowledge base, “show me the diff” beats “trust me.”
• It’s mine, end to end. Runs on my hardware, on my schedule, with a model I point at. No SaaS holds my brain hostage.
• The detection is deterministic; the model only acts. The LLM never decides what’s wrong — a boring query does that. The model only decides how to fix the things already found. That split keeps the whole thing auditable and cheap.

If you already live in a tool that does this and you trust it, great. I wanted the git-diff trail and the local control.

The part I actually want to tell you about

The plan was tidy: I run n8n on the same cluster, so n8n would be the scheduler — fire nightly, SSH into the node, run the gardener. Clean, visual, one workflow.

n8n could not reach the node. At all. Every port: ECONNREFUSED.

This sent me down a genuinely interesting hole, because the homelab runs Cilium for networking, and Cilium has opinions about your own node that plain Kubernetes does not.

First instinct: a NetworkPolicy allowing egress to the node’s IP. Wrote it, synced it, still refused. The reason is a Cilium subtlety worth knowing: the node isn’t a CIDR, it’s an identity. Cilium classifies your cluster’s own node as the special host identity, and ordinary ipBlock CIDR rules do not match it unless you flip a cluster-wide setting (policy-cidr-match-mode: nodes). My 192.168.0.109/32 rule was a no-op.

So I switched to the Cilium-native tool: a CiliumNetworkPolicy with toEntities: [host]. Confirmed it applied — I could see reserved:host allowed right there in the datapath’s BPF policy map. I confirmed the node’s IP really does resolve to identity 1 (host). I confirmed the host firewall was disabled. Everything said “allowed.”

Still ECONNREFUSED.

That’s the wall. The packet leaves the pod with Cilium’s blessing, hits the host’s own network stack, and something there sends a reset — and I couldn’t see what, because inspecting the host firewall needs root, and this automation deliberately doesn’t have it. I could have kept digging with a password. But I stopped and asked a better question: why am I making a pod reach back into the host it’s running on at all?

That’s an awkward direction. The work has to happen on the host (that’s where the vault, git creds, and Claude live). A pod straining to SSH into its own node is fighting the grain of the platform.

So I inverted it. The node schedules itself — a plain cron entry, rock-solid, no network gymnastics. And n8n, instead of triggering the job, receives it: at the end of each run the node POSTs a summary to an n8n webhook. Node→n8n works perfectly (it’s just an outbound HTTPS call to a URL). n8n keeps the run history and is the place I’ll later wire a phone notification.

I lost nothing that mattered. n8n is still my dashboard; the schedule just lives where the work lives. And I deleted the SSH key and the network-policy hole I’d opened — the cleanup felt better than the original plan would have.

The lesson, such as it is

Two, actually.

One: when you’re automating something to run unattended, the bug you want to find is the one that shows up in a dry run at 2pm, not at 3am three weeks from now. I almost shipped a version where a brand-new note (untracked by git) was invisible to my change-detection and would’ve been silently wiped each night. The dry run caught it. Always build the dry run.

Two, the bigger one: I spent an hour trying to make a pod punch into its host because that was my plan, and the platform kept saying no in increasingly specific ways. The fix wasn’t a cleverer NetworkPolicy. It was noticing I was pushing against the design and turning around. The node scheduling itself and reporting up to n8n is simpler, safer, and more honest about where the work actually lives.

My brain weeds itself now. Every morning there’s maybe one small, sensible commit waiting — a link I’d have never made, a summary nudged back to true — and I can read exactly what changed before my coffee’s done. That’s the whole dream of a second brain that isn’t a junk drawer: it stays a garden, and I barely have to touch it.

There are, at last count, a small army of tools that list your Claude Code sessions and let you jump back into one. tmux wrappers (claude-tmux, claunch), keyword resumers (tmux-claude-code), fleet managers (claude-manager), and a whole macOS menu-bar genre (claude-control, cmux, and friends). They’re good. Several are better-engineered than mine.

I built one more anyway.

Not because the others are wrong — because none of them were shaped like my day, and the cost of hand-rolling a 300-line script turned out to be smaller than the cost of bending my workflow around someone else’s defaults. That’s the whole pitch, and it’s a boring one. The interesting part is what I had to understand to build it, because it corrected a mental model I’d had backwards for months.

My day, concretely

I work off a single Linux box over SSH, from a few different machines. A session might be a homelab change, a side project, a blog post. I drop one mid-thought, my laptop sleeps, I pick it up that evening from a different terminal. The thing I kept doing was running claude --resume and squinting at a list of UUIDs trying to remember which 7f3a… was the one about the broken redirect.

I wanted one command — wt — that shows me every session with a human summary and tells me, truthfully, which ones are still alive. Then lets me pick one.

Simple ask. It sent me reading the on-disk format, and that’s where it got educational.

What I had backwards: tmux is not how you keep a session

Every tmux-first tool sells the same promise: run Claude inside tmux so your session survives a disconnect. I’d internalized that as “tmux is how Claude sessions persist.”

That’s wrong, and realizing it deleted half the code I thought I’d need.

A Claude Code session is one claude process, keyed by a sessionId UUID. Its entire transcript — every message, every tool call and result — is appended to a file:

~/.claude/projects/<cwd-slug>/<sessionId>.jsonl

It’s append-only, and it has no “end” marker. When you --resume, Claude reopens that same file and replays it. One of my session files spans three calendar days across half a dozen resumes — same file, same UUID, the whole conversation reconstructed from disk each time.

Which means: the history is durable independent of any running process. You do not need tmux to land exactly where you left off. claude --resume <id> does that from the transcript alone, on a box with no tmux installed at all.

So what is tmux for, then? Exactly one thing: keeping a process running while you’re disconnected — a long job, an agent grinding away, or re-attaching the same live process from your phone. That’s real, but it’s the exception, not the default. So in my tool, plain resume is the default and tmux is an opt-in flag. The inversion fell straight out of reading the format honestly.

The other thing the transcript doesn’t tell you: is it alive?

Here’s the subtle bit. The transcript tells you the history of a session. It does not tell you whether a claude process is running right now. There’s no “closed” record — the file for a long-dead session looks identical to one you left open thirty seconds ago.

Liveness lives somewhere else:

~/.claude/sessions/<pid>.json   →   { pid, sessionId, cwd, procStart, ... }

A session is alive if that pid is actually running. But you can’t just trust the file’s existence — it can linger after a crash — and you can’t just kill -0 the pid either, because the kernel recycles pids and you might be poking a process that reused the number. So the honest check is two-factor:

def alive(pid, procstart):
    try:
        os.kill(pid, 0)          # exists and signalable?
    except (ProcessLookupError, OSError):
        return False
    # ...and is it the SAME process, not a pid-recycle?
    stat = Path(f"/proc/{pid}/stat").read_text()
    starttime = stat[stat.rindex(")") + 2:].split()[19]
    return starttime == str(procstart)

That /proc/<pid>/stat start-time comparison is the difference between “I think it’s live” and “it’s live.” It’s the kind of detail you only get right by caring about the boring case.

With that, every session resolves to a real state:

• ● live — a process is running now
• ⧗ waiting — no process; you left mid-conversation (last line was Claude)
• · idle — no process; stale

And the payoff for getting liveness right: if you try to resume a session that’s still live in another terminal, the tool refuses to double-open it — two processes appending to one transcript is how you corrupt your own history — and offers a clean --fork-session instead.

The summaries were free the whole time

The feature I assumed I’d have to build — a short, human description of each session — I didn’t build at all. Claude Code already writes one. Buried in the transcript is a record type:

{"type": "ai-title", "aiTitle": "Investigate nested o directories", "sessionId": "..."}

Claude titles your sessions for you. The “summary” column in my tool is just that field, with a fallback to your last prompt. The best line of code is the one you delete after noticing the platform already did the work.

So what did I actually build

Not much, and that’s the point. wt is one Python file, standard library only, no daemon. It globs the transcripts, reads each one’s title and last-activity, joins that against the pid-verified live registry, sorts live-first, and prints a numbered list. Pick a number and it execs into claude --resume. There’s a -t for tmux when I genuinely need it, a d to archive old sessions (a file move, fully reversible), and a guarded hook that turns it into an SSH login greeting so the box tells me what’s on it the moment I land.

  watchtower · 5 session(s)
   1) ●  live       16s  homelab    595e931d  Investigate nested o directories
   2) ·  idle     1d07h  notes-app  6565b121  Migrate to server components
  [#]resume  [t#]tmux  [d#]archive  [n]ew  [Enter]shell  [q]uit ▸

If you want it, it’s on GitHub, MIT. But honestly, I’d rather you take the three things I had to learn than the tool:

1. Your Claude history lives in a plain append-only JSONL on disk, not in tmux. --resume works without any wrapper. Back up ~/.claude/projects/ and you’ve backed up every conversation you’ve had.
2. Liveness is a separate fact from history, and checking it honestly means verifying the pid is the same process — not just that something answers to the number.
3. The platform probably already did the boring work (here: the titles). Read the format before you write the feature.

The flooded-market thing turns out not to matter. A tool that fits your own hands is worth building even when fifty others exist — especially when it’s small enough that “build” and “understand the system underneath” are the same afternoon.

I wanted to get a feel for AI-assisted coding tools — Claude Code, Codex — in a low-stakes environment where breaking things was fine. A browser game seemed like the right vehicle: self-contained, no prod database, no users to disappoint.

I picked a premise I knew was fun: Dice Wars. The Flash-era classic. Roll dice to attack adjacent territories, biggest army snowballs. Simple enough that I could focus on the tooling rather than the design. Or so I thought.

Six weeks later I had five asymmetric character classes, a procedural hex map generator with acceptance criteria, a FastAPI telemetry service recording every dice roll, and a stat dashboard I check more than I probably should. The tooling became a background concern. The game took over.

How the game works

The rules are genuinely minimal.

You start with a random slice of a procedurally generated map — a patchwork of irregular coloured territories, each one a cluster of hex tiles that reads as a solid blob. You and up to seven opponents begin scattered across it. Objective: own everything.

Attacking is one click. Select your territory, click an adjacent enemy territory. Both sides roll all their dice and sum. Higher total wins. Attacker wins: you capture the territory, your dice advance in minus one. Defender wins: your attack is repelled, you’re reduced to a single die on the attacking territory.

Reinforcements are the mechanic that makes this a strategy game. At the end of your turn, you receive bonus dice equal to the size of your largest contiguous group of territories. Not total territories — the biggest connected blob. Fragmented territory generates almost nothing. A solid connected bloc snowballs.

That one rule creates the entire strategic texture. Grab fast but stay connected. Chokepoints are worth defending at a loss. Cutting an opponent in half collapses their income immediately. The late game turns into tense standoffs until one roll cracks something open.

The shrines

Early on I added shrines — special territories marked with a ★. They behave differently from normal territories in a few ways:

• Higher dice cap: normal territories max out at 8 dice, shrines at 10
• Minimum floor: a shrine never drops below 2 dice after attacking, win or loss — it can’t be stripped bare
• Guaranteed reinforcement: the shrine gets a die first at end of turn, before random distribution
• Aura: each of your own territories adjacent to the shrine gets a +1 guaranteed die (shown with a dim ◆ indicator)

The shrine mechanic does something interesting to the risk calculus. Holding a shrine isn’t just a territory — it’s a node that warps the value of everything adjacent to it. You’ll defend an aura territory harder than a territory of equivalent size elsewhere on the map, because losing it means losing the aura bonus. It also means attacking into a shrine aura is expensive: the shrine can’t be worn down easily, and the neighboring territories keep refilling.

Shrines turned out to be the moment the math got interesting.

Five guardians

The game has a character select screen. Each player — human or AI — picks a guardian before the map generates. Five options, each with a passive and an active ability that meaningfully change how you play:

Hippo gets to manually place one reinforcement die each turn before the rest distribute randomly. One die placement doesn’t sound like much until you realise you always have a frontline territory that needs it more than anywhere else. High floor, consistent.

Hedgehog fills weakest territories first during reinforcement. Defensively solid — you never bleed out a border territory to zero while inland territories sit at cap. It doesn’t generate more dice, but it wastes fewer.

Fox banks a stored die every other turn and can spend it as a critical multiplier on an attack. The stored dice accumulate (up to a cap), so the power compounds if you resist using it. Two-hop flanking passive: Fox can attack across two territory hops from border territories, making it very hard to feel safely tucked away from.

Owl has a passive two-hop attack range like Fox but for all attacks — Owl sees further. The active ability is a Dice Transfer: move dice from one of your territories to an adjacent friendly one. Lets you concentrate force without committing to an attack.

Turtle gets 2 dice back to a neighboring territory any time it loses a defense. It’s the only guardian that turns taking damage into a resource. Hard to snowball, but very hard to finish off.

The AI cycles through the five guardians deterministically, so in a full 8-player game you’ll face at least one of each.

The map

The map generator produces irregular coloured territories from a hex grid. Hexes are the visual scaffolding — what matters in gameplay is the blob they form. Internal edges within a territory are hidden; only the outer border of each cluster is drawn. The result reads like a contested piece of ground rather than a grid.

The generator has acceptance criteria. A proposed map is rejected if territory sizes are too uneven — a tiny starting territory with 2 hexes versus a sprawling 15-hex territory produces a wildly unfair game. The stats service actually records generation attempts and acceptance rates per map, so I can see how often the map generator throws away its own work.

The mapId is stamped on every game record, so I can eventually correlate map topology with game outcomes. I haven’t done that analysis yet, but the data is there.

What the tools actually felt like

Claude Code handles the kind of work that benefits from holding a lot of context simultaneously: “this change to resolveAttack() in game.js needs corresponding updates to the AI logic in ai.js and the render pass in render.js.” That’s tedious to track manually and exactly the kind of thing where the tool earns its keep.

Codex was more useful for the boilerplate-heavy parts — filling in schema.sql, wiring up FastAPI endpoints, the chart.js setup in the dashboard. Directed generation of code you know exactly how should look.

Neither tool replaces thinking. The guardian ability design, the shrine balance, the question of whether Fox’s stored critical is too swingy in epic mode — that’s all still just sitting down and working it out. The tools speed up the translation from “I know what I want” to “here is working code.” The game design itself doesn’t compress.

It’s live

The game runs at dice.hippotion.com. Single HTML file served from a Kubernetes ConfigMap on my homelab. No accounts, no install. It runs fast — AI turns are instant when you toggle off animations, and a full game can be over in five minutes or stretch to twenty depending on how the map falls.

Stats dashboard at game-stats.hippotion.com. More on that in the next post.