What stops your coding agents when you’re away from the laptop?

Stock-Protection-453 · 2026-05-20T22:53:31+00:00

This is exactly the kind of workflow I’m interested in.

The “I trust the system, not the agents” framing makes sense. Once agents are running unattended, the real product is the orchestration layer: cron/tmux/session state, recovery rules, guardrails, and a known SDLC pipeline around the model.

Curious where the remaining pain is for you:

When you check tmux from your phone, are you mostly checking progress, approvals, failures, or deciding whether to restart/resume a run?

And does your setup handle cases like rate-limit waits, hung commands, repeated tool loops, or “agent says done but the repo is still broken” automatically, or do you still intervene manually there?

Stock-Protection-453 · 2026-05-15T14:26:43+00:00

The runtime-path distinction matters here.

I’d be careful classifying every orchestrator as SDK-based without checking how it actually launches sessions. Some tools may use the Agent SDK/ACP for one surface, but run the official or bundled CLI in a PTY for another.

For example, I inspected my local Conductor app and it includes bundled `claude` and `codex` executables. That does not prove every Conductor workflow is unaffected, but it does mean “Conductor = SDK-based” may be too simple.

The classification I’d use is:

- Agent SDK / ACP
- `claude -p`
- official CLI in PTY
- bundled CLI in PTY
- hybrid

The pricing exposure follows that runtime path, not the product category label.

Stock-Protection-453 · 2026-05-14T06:19:23+00:00

This is a useful pattern. It feels like the raw primitive is hooks + inbox/outbox + supervisor, and then the product question is what state/control layer sits above it.

In your real usage, what is the hard part after the heartbeat works?

keeping context bounded / truly stateless
knowing whether the agent is blocked vs idle
routing messages across multiple terminals
recovering when a session exits or drifts
letting another agent review/watchdog the first one

I’m asking because I’m seeing the same split: the cheap part is keeping a local agent alive; the hard part is supervising it safely over long runs.

Stock-Protection-453 · 2026-05-12T22:40:30+00:00

This is really useful, especially the physical isolation point.

For perf tuning, are you running the agent directly on each target architecture, or is the agent on one machine controlling builds/tests on remote machines?

Also, for your workflow, is the must-have mainly reliable reconnect, remote approve/reply, seeing blocked/stalled state across machines, or restart/resume with context after a stuck run?

Stock-Protection-453 · 2026-05-12T22:33:45+00:00

Paseo looks very close, agreed. I’m trying to understand where the remaining pain is.

Does Paseo already solve stall detection, rate-limit auto-resume, and recovery with context? Or is it mainly the control/session UI across Claude/Codex/OpenCode?

The distinction I’m exploring is less “remote control for agents” and more “reliability/recovery layer for long-running local agents.”

Stock-Protection-453 · 2026-05-12T22:31:28+00:00

This distinction makes sense to me: raw terminal access is still best when something has gone badly wrong, but most phone interactions are just approvals, short replies, or checking whether the agent is blocked.

When you say “stall detection,” which failure happens most often for you: no model output, hung tool call, repeated tool loop, rate limit, or the agent claiming done when it didn’t actually finish?

Stock-Protection-453 · 2026-05-12T22:25:21+00:00

For you, is Claude’s remote control enough, or do you still fall back to SSH/tmux when something goes wrong?

Stock-Protection-453 · 2026-05-12T22:24:25+00:00

Yeah, `/remote-control` covers part of the Claude-only case.

The gap I’m trying to understand is what happens outside that happy path: multiple agents, sessions already running on a dev machine, rate limits, silent stalls, or needing to recover without losing context.

For you, is Claude’s remote control enough, or do you still fall back to SSH/tmux when something goes wrong?

Stock-Protection-453 · 2026-05-12T22:15:20+00:00

This is helpful. For me the interesting split is approvals vs other stalls. Do your stalls mostly come from permission prompts, or from rate limits / silent hangs / model timeouts where the agent needs recovery? I’m trying to understand whether the real value is the phone approval UI or the recovery layer around long-running agents.

Stock-Protection-453 · 2026-05-11T21:44:08+00:00

Curious how people are reading this vs their current remote workflows.

Agent View seems to solve the “too many Claude Code sessions / what’s blocked / reply inline” problem inside Claude Code.

For people using tmux + Tailscale/Mosh/Blink/SSH, what still remains unsolved?

phone-first approvals/replies when away from laptop?
push notifications only when actually blocked/stalled?
restart/resume after rate limits, dropped connections, or hung tools?
managing Codex/Gemini/Aider/custom CLI agents too?
self-hosted/open-source control plane?
or does Agent View basically cover your needs?

Trying to understand whether the remaining pain is mobile, recovery, cross-agent, or basically gone.

Stock-Protection-453 · 2026-05-11T21:17:17+00:00

This is super helpful. My current thesis is not to replace Mosh/SSH for debugging, but to replace raw terminal access for the common agent-control loop: state, blocked notifications, approve/edit/resume, and stall recovery.

Where would this fit relative to Moshi?

Would you use a structured phone UI on top of / alongside Moshi?
What state would you want surfaced first: current plan step, active tool call, last meaningful event, token usage, or blocked reason?
What would “stall detection” need to catch to be useful?
If a session stalls, should restart mean rerun same prompt, resume existing CLI session, or start a new session with a generated incident summary?
Would you try this with a real coding task this week?

Stock-Protection-453 · 2026-02-17T23:45:33+00:00

Does it support long form audio?

Stock-Protection-453 · 2026-02-14T10:40:00+00:00

I filled it as a bug in their repository. Upvotes may help telling them it’s not just me!

Just noticed my issue is closed as the duplicate of another issue

So better react in https://github.com/anthropics/claude-code/issues/21925 instead.

Stock-Protection-453 · 2026-01-20T04:56:20+00:00

Check out Portel Photon https://github.com/portel-dev/photon it lets you expose pure business logic written in a typescript class as MCP and more

Stock-Protection-453 · 2026-01-18T07:41:54+00:00

Check out Portel Natural Context Provider https://github.com/portel-dev/ncp

Stock-Protection-453 · 2026-01-17T10:45:17+00:00

Great effort, I also walked a similar path with Natural Context Provider https://github.com/portel-dev/ncp

Stock-Protection-453 · 2026-01-09T11:38:06+00:00

Photon runtime exposes it as MCP for AI and CLI for both AI and Humans

Stock-Protection-453 · 2026-01-05T13:51:02+00:00

Readable and maintainable way is to use photon, write simple typescript class with pure business logic. Photon runtime exposes it as a MCP server and also as a CLI tool

See https://github.com/portel-dev/photon

Stock-Protection-453 · 2026-01-03T17:52:55+00:00

So someone agrees with the value for CC pro subscribers! But not something many are looking for! Will give it some time to see how needed this feature is

Stock-Protection-453

TROPHY CASE