AgentHub

The deciding trait is the diff pane. You read the change side by side and send the correction straight back into the session that made it, which removes the copy-paste step that makes reviewing agent output tedious. That single loop is why you would keep the app open rather than opening it when you remember.

It is wrong for anyone who runs one session at a time, where a grid of cards is decoration rather than a view. Pick it if you fan work across several sessions and want the review in the same window. Pick tmux if your habits already live in the terminal.

The weak joint is discovery. Sessions are found through file-system watchers over state another vendor writes, which means the app reads a private format it does not control. When that format shifts in a routine update, the grid does not error; it shows fewer sessions than exist, and nothing tells the user which ones are missing.

The same dependency runs through worktree creation and session resume, both of which assume the vendor keeps its identifiers stable. What it does right is the embedded terminal: a real PTY per card means the fallback, when discovery fails, is the tool you were going to use anyway.

1. Most review surfaces terminate at display. Here the diff pane is an input as well as an output, so the correction re-enters the agent's context in the same session rather than as a fresh prompt with the history lost. 2. That preserves the provenance of a change, which matters when a later edit needs to be explained.

2. The Smart launcher, which plans a multi-session run before starting it, is asserted rather than demonstrated: no evaluation accompanies the planning step and no account of how the plan is produced appears in the documentation. The verification story is strong for single changes and undocumented for orchestrated ones.

This is a personal project with unusual polish and no commercial structure behind it. Stars measure attention, not revenue, and there is no hosted tier, no paid seat and no entity to sign a contract with. Moat: none, because the value is a well-made shell over runtimes two large vendors control.

Likely path: either those vendors absorb this feature set into their own apps, which costs them a quarter, or the author's interest holds and it stays excellent and small. There is no acquirer here, only a hiring manager. Position: use it, and keep your work reproducible from the command line underneath.

The blocker is the fleet. It runs on macOS and nothing else, so a mixed estate cannot standardise on it and I end up supporting two workflows instead of one. Where the hardware is uniform, the finance side is trivial: no seat price, and the model spend stays on subscriptions we already reconcile.

The build is signed and notarised, which is the one line that makes distribution through our device management a form rather than an argument. There is no single sign-on, no audit trail and nothing that runs in a pipeline. Approved with conditions: uniform hardware, managed distribution, and no expectation that it reports anything upward.

The interesting part is that it ships an MCP server rather than only consuming one. Tools such as agenthub_record_measurement become available to the sessions it hosts, and for Codex it is a line in ~/.codex/config.toml that I write and version like anything else. That is a real extension point, not a plugin menu.

MIT means the fork survives the author, though a Swift codebase narrows the pool of people who would maintain it. It brings no model, which I count as honesty: my logins stay mine. Grudging respect for a native app that does not pretend to be a platform.