Timeline

I shipped v1.12.2 of tmux-agents, a patch release with two fixes that bring behaviour in line with the docs. Renaming and auto-naming now keep the agent kind prefix for agents started with tmux-agents start, so renaming a chain's main to main gives claude-tmux-agents-main instead of tmux-agents-main, and Codex profiles consistently use codex-. Top-level agents, like a chain's main, now go idle when they finish a turn with nothing pending instead of showing amber "needs you", which stays for sub agents and members.

I shipped v1.12.1 of tmux-agents, a small fix for tmux-agents start in a named pane: when you run it from that pane's own shell, it now takes over the pane, keeping its name and connections, and --name renames it first. Before, it refused to start from any named pane.

I shipped v1.11.0 of tmux-agents with long-lived members (tmux-spawn --member), which the agent-chain skill now uses for its secondary and worker instead of sub agents. The agent list is calmer: a fixed name column, compact names, time in state and worked time per agent, plus a pinned preview header with full activity and scrolling that pauses follow. The list now requires fzf and gives clear install instructions when it is missing; there is also a new configuration guide and an updated quick start. After updating, reload the tmux config with tmux source-file ~/.tmux.conf so the new hooks can save worked time and mark removed panes closed.

I shipped v1.10.0 of tmux-agents with one shared skill for Claude and Codex, installable with npx skills add TheClooneyCollection/tmux-agents -g, and a new agent-chain skill for “start the chain”: main, secondary and worker side by side. The installer now handles Codex homes more safely, backs up real files and directories with --force, and warns about dangling skill links; re-run ./install.sh from the installed checkout after updating. CI runs on macOS and Ubuntu, covering installation and upgrades as well as the offline tests. Picker rows now stay aligned, and searches match only agent names and projects.

I shipped v1.9.0 of tmux-agents with hidden agent ids behind the readable names: session records, parent links, waiting lists and queued messages now use ids, so reusing a closed agent's name cannot overwrite its saved conversation, a real bug we found while checking renames. Renaming now changes only the label; names remain unique among live agents and are still how we address them, with ids kept out of the agent list rows. Agents can look up ids with tmux-peers --ids or tmux-spawn --list-closed, and use --resume-id to reopen one exact closed agent when names repeat. Existing setups migrate on first use with a backup of the old records, preserving every resumable conversation and parent link, checked on a copy of my 54 real records.

I published How To Move Fast and NOT Break Things with AI, about the point where using an agent's name as its id stopped fitting tmux-agents. It covers the move to real ids in progress for v1.9.0, and the tests, decision records and release rules that grew out of real use. The lesson is to prototype fast, then add structure where the problems show up and leave guard rails for the next agent.

I shipped v1.8.0 of tmux-agents with tmux-rename: an agent's links, saved records, references from other agents and queued messages follow the new name, and it and its connected agents get a notice. Agents can rename themselves and their descendants, while I can rename anyone. Given names now follow the automatic format, so tmux-spawn codex --name spirit-earth creates codex-<project>-spirit-earth, with --exact to keep a name as given. Every user setting is now a live tmux option in tmux.conf (set -g @tmux_agents_<name> ...), listed in one Configuration section, with the old environment variables still taking precedence.

I shipped v1.7.3 of tmux-agents, rewriting AGENTS.md around what the agents learned shipping v1.6 and v1.7. It now covers running tests, treating flaky tests as release blockers, the list-build process budget, working in a shared checkout and recording decisions before implementation. The release routine says to reply as soon as a release is out and never move a published tag, while the DESIGN.md overview now matches current behaviour.

I shipped v1.7.2 of tmux-agents, a documentation update bringing the Chinese README back in sync with the English one. I also added a rule to keep both versions in sync from now on.

I shipped v1.7.1 of tmux-agents so prefix + a shows the popup in about 50ms, instead of waiting 0.5–0.7 seconds before anything appears: fzf starts immediately and loads the rows right after. The bigger delay was in my shell, since tmux runs every popup through default-shell -c: my fish config loaded thefuck and mise even for non-interactive shells, costing 0.26–0.47 seconds each time, and now stops early in 0.01–0.02 seconds. I added performance notes, an “If popups feel slow” check in the README and a tmux-agents-perf skill to help agents find where a delay comes from.

I shipped v1.7.0 of tmux-agents so tmux-ask keeps waiting messages instead of giving up on a busy pane, with “✉ message waiting” pinned in the agent list and shown in the chip after 30 minutes. If the receiver is gone, the sender gets a notice with the saved text's path; messages for reopenable spawned agents are kept for tmux-spawn --resume, while tmux-ask --pending lists queued or undelivered messages and --retry re-sends them, including files from older versions, with at-least-once delivery. The list also opens and switches scope about 45 times faster on my live data (28 panes and 45 session records), from 4.5 seconds to 0.1 seconds, by using one tmux snapshot instead of hundreds of tmux, awk and git calls; a new test fails the build if a rebuild launches more than 20 processes. The worker split the work across three agents of its own, with decisions recorded.

I shipped v1.6.1 of tmux-agents, a skills update telling agents to reply as soon as a request's main work is done, then send follow-ups such as a deploy or a page going live as notices. For requests with several parts, they send a notice as each part lands. It came from my agent chain: secondary held its v1.6.0 reply until the blog entry was live, leaving main and me unaware that the release was already out.

I shipped v1.6.0 of tmux-agents so one tmux-dismiss closes the secondary, worker and the rest of their subtree, deepest first and with each agent reopenable; agents can close any descendant, while --keep-children leaves children running without an owner. An agent waiting for its first task now shows “○ idle”, and an agent that sends its parent a progress notice and waits no longer gets flagged “needs you”, a bug I saw with spirit-earth. Closed agents whose parents were also closed now appear in the right window's list. The worker split the work across three agents of its own, with decisions recorded and 199 checks, including the new tests/dismiss.sh.

I shipped v1.5.0 of tmux-agents after running several projects at once: prefix + a now opens the agent list for the current window, including its agents and their spawned descendants in hidden windows or splits, with ctrl-t to switch to all windows. Agents waiting for permission or marked “needs you” stay pinned at the top across all windows, longest wait first and labelled with their project and the visible window they belong to (their first visible ancestor’s), so the filter never hides something waiting on me. The status-bar chip stays global on purpose. The decisions are recorded, and tests/list-scope.sh covers the list behaviour.

I shipped v1.4.0 of tmux-agents so spawned agents can open in a visible split with tmux-spawn --split <pane> [--right | --below] [--size N%]. It came from the layout I wanted for my agent chain: main on the left half, secondary top right and worker bottom right, all in one window, using --split main --right for secondary and --for secondary --split secondary --below for the worker. Split agents keep the agent list, status chip, messaging, closing and reopening, though reopened agents return in hidden windows. The decisions are recorded, and tests/spawn-split.sh covers the feature with 43 checks.

I shipped v1.3.2 of tmux-agents, a documentation update naming the middle role in my agent chain “secondary” instead of “coordinator”: main → secondary → worker. The guide, both skills and the spawn-for tests now use the name I chose. Agent behaviour is unchanged.

I shipped v1.3.1 of tmux-agents after a spawned agent on the Stone Age project showed “needs you” when it reported progress just after replying to its parent. A report such as “delivered abc123” now leaves a completed agent done, instead of putting it back to work and flagging it at the next turn end. A new regression case in tests/needs-you.sh covers the sequence.

I shipped v1.3.0 of tmux-agents to support the main → coordinator → worker chain: tmux-spawn --for <owner> lets main spawn a worker that belongs to and connects only to the coordinator, which introduces itself and sends the first task. The worker starts without a task, and depth counts from main so it can still spawn agents of its own. I also fixed messages to closed agent names landing in similarly named windows; missing names now fail, and agents are told to use the names tmux-peers shows now. Product decisions live one per file, with new regression tests for ownership and name matching.

I shipped v1.2.1 of tmux-agents after finished spawned agents showed “needs you” when their parent broadcast a rule as a request. Agents now use tmux-ask --notice to pass along information, so a request saying “no reply needed” doesn't put an idle agent back to work. Notices also preserve a Claude agent's waiting state while background work runs, and regression tests cover both false alarms and cases that really need me.

I published Your Sub-Agents Shouldn't Disappear: Meet tmux-agents, the introduction to tmux-agents that my last two posts kept pointing back to. It covers why I wanted visible sub-agent sessions, how I use them on my game and this blog, and how to try the tool. I also wrote down a few of the design choices and the limits I'm still working through.

I published Messy Chat with Your Agents? You Just Need One More. Really., about splitting the Claude agent I talk to from the one coordinating work on my Stone Age remake. With tmux-agents, the new main agent has one peer: the coordinator, which handles the main Codex agent and its sub-agents. The post shows the setup before and after, why my conversation got quieter, and the extra hand-off that comes with it.

I published I Gave My Coding Agents a Shared Worktree Pool, about the worktrees Claude and Codex left behind while I was building my Stone Age remake. I run those agents through tmux-agents, which I shipped the day before. I replaced fresh checkouts with reusable slots and shared asset folders, then made a general Python version available as a gist. The post covers the lease rules, the disk cleanup that prompted them, and what I have and haven't tested yet.

I shipped v1.0.0 of tmux-agents, extracted from my dotfiles with its full history and released under MIT, because I want my sub agents' work to stay visible after the task ends. Each Claude or Codex sub agent runs in its own tmux window: I can watch a live preview, switch in to steer it, and let agents exchange tasks and replies through tmux-ask. The panes stay until closed, the conversations can be resumed afterward, and a line above the status bar flags agents that need me. There's also a setup skill so an agent can install it and walk me through a quick start.

Cut v1.0.0 of little-snitch-review-kit, a personal workflow I use for reviewing Little Snitch exports with an AI assistant.

The Little Snitch UI is great at intercepting one connection at a time, but it does not answer the longer questions I actually care about: what is this process talking to over a week, and which observed traffic has no explicit rule covering it.

This release bundles the analysis scripts (per-app rollups, uncovered pairs, denied traffic), the importable .lsrules builders (HaGeZi Pro and reviewed consolidation plans), and the docs and tests around the human-in-the-loop review workflow. The core constraint stays: scripts surface candidates, humans make the trust decisions.

I've been iterating on scripts/check_cloudflare_pages.py, and this one ended up being a pretty clean example of where Claude currently feels stronger than Codex for TUI / UI design.

Codex got the script started and helped shape the core deployment-status workflow, but when it came to making the terminal output feel actually polished, especially across both the short and verbose views, Claude was noticeably better. At its best Codex still seems to struggle a bit with this kind of presentation work, so I ended up handing the UI pass over to Claude even though Codex had started the script.

View	Codex	Claude
Short version
Verbose version

I tagged a ProjectSpire snapshot for 2026-05-11, but this one feels different because I barely did any of the implementation myself.

My Codex usage is nearly gone, so Claude carried most of the work while I was busy elsewhere: parsers for relics, potions, events, and monsters; shared parser utilities; tests; and a few devlogs.

I haven't built the UIs I need to verify Claude's parser work against the actual game properly. So I don't have that confidence in its work yet without the validation.

I miss Codex and the clearer feedback loop, the back and forth, and...

Most importantly my own deeper understanding of how everything ties together.

Tomorrow. Today has been a long day.

After a few weeks working on ProjectSpire with Codex, I’m leaning toward it as my default for software engineering projects. The main frustration has been hitting the Pro account limit; otherwise the quality has been good, the interaction feels responsive, and the output gives me instant feedback while it works. Claude Code still feels more like a black box to me: it can disappear into minutes of research and thinking on its own, and the effective limit feels lower. That tradeoff matters, because for this kind of project I want a tight engineering loop more than a long silent reasoning pass.

Shipped Card Parser v0.2.3 to ProjectSpire, which adds calculated variable resolution, numeric symbol extraction, and conditional text formatters. Cards like Ashen Strike now show computed damage values instead of raw placeholders, and I've added choose, cond, inverseDiff, and boolean formatters for rendering conditional card text. The parser now threads card type, target type, and runtime display vars (HasRider, Sapping, Energized, etc.) through text resolution, making the pipeline much more precise about card state and context.

# Human-AI collaboration: architect and developer

The whole card parser has been built in this mode: I act as architect, GPT-5.5 acts as developer. Every meaningful parser improvement came from me inspecting concrete generated JSON against real card examples and asking source-fidelity questions. GPT-5.5 didn't discover that cost upgrades can be negative, or that Bash's upgraded Vulnerable value wasn't being applied, or that X-cost cards needed their own shape. I did, by reading the output and comparing it to what the game actually does.

The pattern that emerged: I'd spot a class of issue on a specific card, explain what the game source was doing and why the output was wrong, and GPT-5.5 would produce a working fix. Then I'd push to turn each discovery into a repeatable check rather than a one-off patch. The coverage audit script, the unresolved placeholder CSV, the hard failures on missing source files: all of those came from me steering toward systemic fixes after catching individual bugs.

What GPT-5.5 is good at in this loop is the mechanical throughput. Regex extraction, threading new state through a resolution pipeline, mirroring changes to the audit script, regenerating 55 JSON files, splitting work into clean commits. The domain knowledge, the quality bar, and the architectural decisions all come from the human side. GPT-5.5 doesn't know what CalculatedVar means in the game engine or why display vars like HasRider matter for conditional text. It doesn't need to, once I describe the shape of the problem clearly enough.

The productivity gain isn't just speed. It's that I can stay at the architectural level, thinking about which cards are still wrong and why, without losing momentum to implementation mechanics. The feedback loop stays tight: inspect, identify, describe, implement, verify, repeat.

# Example: resolved card output

Here's what a fully resolved card looks like now. Ball Lightning's resolved block shows the base and upgraded display states, with structured text runs that carry source variable references and style annotations:

		
  "resolved": {
    "base": {
      "title": "Ball Lightning",
      "cost": 1,
      "energy_cost": {
        "kind": "int",
        "value": 1
      },
      "description": {
        "plain": "Deal 7 damage.\nChannel 1 Lightning.",
        "runs": [
          {
            "text": "Deal "
          },
          {
            "text": "7",
            "source_var": "Damage"
          },
          {
            "text": " damage.\n"
          },
          {
            "text": "Channel",
            "style": "gold"
          },
          {
            "text": " 1 "
          },
          {
            "text": "Lightning",
            "style": "gold"
          },
          {
            "text": "."
          }
        ]
      }
    },
    "upgraded": {
      "title": "Ball Lightning+",
      "cost": 1,
      "energy_cost": {
        "kind": "int",
        "value": 1
      },
      "description": {
        "plain": "Deal 10 damage.\nChannel 1 Lightning.",
        "runs": [
          {
            "text": "Deal "
          },
          {
            "text": "10",
            "source_var": "Damage",
            "style": "green"
          },
          {
            "text": " damage.\n"
          },
          {
            "text": "Channel",
            "style": "gold"
          },
          {
            "text": " 1 "
          },
          {
            "text": "Lightning",
            "style": "gold"
          },
          {
            "text": "."
          }
        ]
      },
      "changed": [
        "description"
      ]
    }
  }
}
	

I’ve been working since last night and today with agents to document how Slay the Spire 2 works, prototype a Spire API and a REST API on top of it, and shape a WIP card parser that turns C# into JSON structures. That work is captured in ProjectSpire snapshot/2026-04-19, which gives me a concrete snapshot of the game model and tooling so far.

I’ve set up ProjectSpire Lab so I can run a script that pulls a decompiled copy of Slay the Spire 2 for local experimentation; the game code itself stays out of Git because I do not have a license to commit it. The setup lives in NicholasClooney/ProjectSpire. It gives me a clean foundation to build mod tooling from.

This grows out of Cloudflare Build Notifications via Email Routing and Email Worker, but I’m now moving the Email Worker out of the Cloudflare dashboard editor and into Git in NicholasClooney/cloudflare-email-to-webhook-worker. The goal is to keep the worker version controlled, review changes before deploys, test locally, and configure it with Wrangler instead of only editing it in the Cloudflare web UI. Right now it is still mostly Wrangler init plus the example email worker, but that is a solid foundation to build from.

I created git-activity in a631c98 so I can quickly answer "what have I been working on?" It walks a directory tree, finds the Git repos underneath it, and shows the latest log entries from each one in a single pass. It also supports a few filters, which is handy when I only want to review a slice of recent work; for example, from my projects folder I can run:

git-activity -r blog -m feat -x chore

That recursively scans repos, focuses on feature work, and leaves chores out of the list.