Agent Monitor (experimental)
A rough orchestration sample bundled with the TermFlow source tree that watches agent CLIs running in terminals and chains prompts through them. Treat it as a reference to read, not a shipped feature to rely on.
agent-monitor (v2.0.0) is an early prototype that predates TermFlow's current ports and auth model. It still points at legacy sample ports and needs a freshly minted token on every run. Nothing below is a supported product surface — it is example code you can learn from or adapt.
What it is
agent-monitor is a small Node/TypeScript program that lives in the agent-monitor/ folder of the TermFlow source repository. It connects to the local API over REST + WebSocket and:
- Detects agent CLIs (Claude, Gemini, ChatGPT-style tools) by watching terminal output,
- Tracks the prompt lifecycle — when a prompt starts, when it finishes, and how long it took,
- Chains prompts — keeps a queue and sends the next prompt only after the current one completes,
- Streams events from the API over WebSocket, with automatic reconnection.
Why it is experimental
The sample was written against an older build, so its defaults no longer match a current TermFlow install. You would have to change them by hand before it connects to anything.
| Setting | Sample default (legacy) | Current TermFlow default |
|---|---|---|
| REST API base | http://localhost:3001 | http://127.0.0.1:42031 |
| WebSocket | ws://localhost:9876 | ws://127.0.0.1:42031/ws |
| Auth | a bearer token minted from a running instance | the config authToken shown in Settings → Connections |
The token is the biggest sharp edge: the sample expects you to paste a fresh token into its .env, and it does not survive an app restart. In today's TermFlow the credential that actually matters is the authToken in Settings → Connections, and on the default localhost binding every endpoint is unauthenticated anyway (see Local API and auth). So the sample's token dance is mostly historical friction.
An honest note: This code is kept for reference, not maintained as a feature. Ports, endpoints, and the token flow have moved on since it was written, so expect to read the source and adjust it before it runs. If you just want the described behavior — detect an agent, wait for it to finish, send the next prompt — you will get further building it fresh on the documented API than resurrecting this sample.
What to use instead
Everything agent-monitor demonstrates is available on the stable, documented surface:
- Prompt chaining and fan-out map directly onto Execute and batch.
- Live output events come from the WebSocket API on the real API port.
- For a monitored, headless fleet with a real UI, use the companion terminal-monitor instead.
Next steps
- Build an orchestrator on REST — the supported way to do what this sample sketches.
- terminal-monitor — the maintained companion dashboard for headless instances.