Four diagnostic commands run one after another means four round trips and four waits. Here they all start at once and the call comes back before any of them are done, so the model can go and do something else and pick up the results later. The trade is that it will run whatever you send it — treat it as a local tool on a machine you own.
An async task runner. You hand it a map of names to shell commands, it starts each one in its own goroutine and returns straight away with a batch id; you then poll for progress, per-task output and exit state.
- submit_tasks — a batch of named shell commands, run in parallel, with the batch id returned before any of them finish
- check_status — overall progress percentage plus per-task command, state and output
- A status per task rather than for the whole batch: pending, running, completed or failed
- Individual failures that do not stop the rest of the batch
- Task names that become part of the task id, so you can poll one task rather than all of them
- A cap of 50 tasks in a single batch
- Asynchronous file logging with rotation, and a configurable log directory
The server binary and a port to run it on. Clients reach it over HTTP, which in Claude Code means bridging with supergateway. Read the security note before pointing it at anything you care about: commands run with the same privileges as the server process, and command-injection protection is not implemented in this release.