Feature Request: Bidirectional Control via NATS

[joeblew999]

Feature Request: Bidirectional Control via NATS

The Problem

Currently clog is publish-only. When Claude Code blocks on a question, I get notified via NATS — but I still have to walk back to my laptop to respond. The notification is helpful, but the workflow is incomplete.

The Ask

Enable bidirectional communication so I can respond to Claude Code remotely:

Claude Code → clog → NATS → My dashboard (notification)
My dashboard → NATS → clog → Claude Code (response)

Use Case

I run long-running Claude Code sessions (refactors, multi-file changes, etc.). I'm often away from my desk. When Claude hits a decision point, I want to:

1. See the question on my phone/tablet/other machine
2. Type my response there
3. Have it flow back to Claude Code

Possible Implementation

• clog subscribes to a response subject (e.g., claude.responses.{session_id})
• When Claude Code asks a question, it blocks waiting for a NATS message on that subject
• Response arrives → clog pipes it to stdout → Claude Code continues

This turns clog from a notification system into a proper remote control interface.

Why This Matters

The "AI coding assistant" workflow assumes you're glued to a terminal. But these tasks can run for 10-30+ minutes. Bidirectional control lets you supervise multiple agents across multiple projects without context-switching between terminals.

I see this mentioned in the README as a future goal — just wanted to register strong interest and offer to help if useful.

[davedotdev]

Thanks for opening this. Something I've been chewing on as well, but didn't want to be the only one going down this path. A solid +1, so thank you.

Throwing some thoughts out there and spitballing a bit.

• I need to experiment a bit with how long the Claude agent could wait for a response from clog and what the process looks like for disconnects and timeouts.
• A response subject needs to be submitted in the message that clog publishes and as per your comment above, clog would subscribe until it gets a response. This enables the raw NATS workflow. That's straight forward enough.
• Do we need a clog user side client? Step one perhaps could be the raw NATS, then step two a clog user client? It could be something lightweight, with JSON in and JSON out on stdout? Something to drive integrations? Even if it was just in the form of a lib? Would that work?

Would love to get some ideas brewing here. This bidirectional feature was on the initial clog todo list, but removed it based on premature feature creation etc.

[joeblew999]

Thanks Dave - glad this resonates.

For the user-side client question, I think narun already covers this. It's an HTTP → NATS gateway (available as a Caddy plugin or standalone binary). Pure config, no code.

The same developer also built nats2sse - NATS to Server-Sent Events. So the notification side is solved too.

The full flow becomes:

clog publishes question (with reply_to subject)
↓
nats2sse streams it to dashboard via SSE
↓
User sees question on phone/tablet in real-time
↓
User types response
↓
HTTP POST → narun → NATS publish to reply_to → clog (waiting) → stdout → Claude Code

Both tools are config-only, no code. So if clog implements step 1 (raw NATS with nats.Request() or subscribe-and-wait), the entire user-side stack already exists:

• nats2sse for real-time notifications
• narun for HTTP → NATS responses

On timeouts - a configurable flag like -timeout=5m with a distinct exit code (e.g., exit 3 for timeout) would let hooks/scripts handle it gracefully. Keeps clog simple and composable.

Once the subscribe side lands, I'm happy to put together a reference implementation - narun config, nats2sse config, simple HTML dashboard. Could live in the repo as an example or separate repo, whatever works.

Looking forward to seeing this come together.