pohunek
You don't need an agentic IDE
The usual answer to running coding agents is a bigger window: an IDE with panes, tabs and a chat box. pohunek takes the other path. The agent is the user of pohunek, and you are the owner who hears about it when it needs you.
A pohunek is a farmhand
A pohunek is the farmhand boy who drives the draft animals. He does not plow himself. He keeps the team moving.
The agents do the plowing. pohunek keeps them running on the right machine, in the right worktree, and tells you or your tooling when one of them needs attention. The name says what the daemon is for, and what it is not for: it does not write the code.
The agent is the user
An agent starts sessions, sends prompts, waits for them to settle, reads the diff and hands work off to the next one.
It does all of that through one contract: a versioned --json envelope on every automation command,
typed errors with recovery hints, pohunek agent-skill that prints the full operating skill an agent
needs, and pohunek assistant that starts an agent already aware of pohunek and your hosts.
pohunek session input <target> --stdin --json pohunek session wait <target> --activity idle --timeout-ms 8000 --json pohunek agent-skill --json pohunek assistant "why does attach fail on my laptop?"
The human is not the terminal
You are not meant to watch a pane of agent output. You go do something else. The record lands in front of you when
an agent is blocked on an approval, from every host at once, through the notification stream. A session keeps
running whether or not anyone is attached to it, and you can take it over with pohunek attach when you
want to, and leave it with Ctrl-] while the agent keeps going.
Why not a multiplexer and ssh
A multiplexer keeps a shell alive. It does not know that the process inside is an agent, so every agent-aware need lands on whoever writes the tool. pohunek handles it once, for every agent CLI.
| You need to | pohunek gives you |
|---|---|
| Know whether the agent is working, blocked on an approval, or idle | Live working, blocked and idle detection from OSC titles, screen patterns and PTY activity. Detection rules are TOML manifests, so a new agent needs no recompile. |
| Submit a multi-line prompt into an Ink TUI without it being half-swallowed | session input with per-agent framing (bracketed paste, delayed submit). Prompts can come from stdin, so they never appear in argv or logs. |
| Hear about it when something needs you, on any machine | Durable notification records (unread, read, acknowledged, archived), fed by agent hooks and daemon-side detection, deduped, and fanned out with --all-hosts. |
| Keep two agents out of one working tree | --branch creates a worktree per session off the base branch. Ownership is recorded and checked before any reuse or cleanup. |
| Get a conversation back, or branch it | Hooks capture the agent session id for an explicit session resume. session fork branches a Claude Code conversation into a new session. |
| Watch without stealing the terminal | session screen, paged session output with exact cursors, and session wait for bounded change polling. |
| Drive it from a script or another agent | One versioned --json envelope, typed errors with recovery hints, subscribe event streams, and Rust and TypeScript SDKs. |
Terminals stay durable, and editors stay yours
Each agent runs on its own durable worker that owns the PTY. Close the terminal, restart or upgrade the daemon, and the session keeps the same PTY and child process. Any editor or terminal can attach, because the attach command is just a terminal. pohunek does not ask you to adopt a particular IDE.
Each host is authoritative for its own sessions, reached over a NetBird or WireGuard overlay with no central server.
Run the team with pohunek. Install it, then see the surfaces that look over the fence.