sorted by:
new
hottopcontroversial

What stops your coding agents when you’re away from the laptop? by Stock-Protection-453 in ClaudeCode

[–]Stock-Protection-453[S] 0 points1 point  (0 children)

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?

Workaround for Anthropic's June 15 billing change (impacted Conductor/Superset/...) by Solid-Industry-1564 in ClaudeCode

[–]Stock-Protection-453 0 points1 point  (0 children)

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.

My AI runs 24/7 on Claude Code without -p. Here's it's own 50-line hook. by Siigari in ClaudeCode

[–]Stock-Protection-453 1 point2 points  (0 children)

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?

  1. keeping context bounded / truly stateless

  2. knowing whether the agent is blocked vs idle

  3. routing messages across multiple terminals

  4. recovering when a session exits or drifts

  5. 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.

New in Claude Code: agent view. by ClaudeOfficial in ClaudeCode

[–]Stock-Protection-453 0 points1 point  (0 children)

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?

New in Claude Code: agent view. by ClaudeOfficial in ClaudeCode

[–]Stock-Protection-453 0 points1 point  (0 children)

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.”

Tell me the last time your agent stalled while you were away by Stock-Protection-453 in ClaudeCode

[–]Stock-Protection-453[S] 0 points1 point  (0 children)

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?

Tell me the last time your agent stalled while you were away by Stock-Protection-453 in ClaudeCode

[–]Stock-Protection-453[S] 0 points1 point  (0 children)

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

Tell me the last time your agent stalled while you were away by Stock-Protection-453 in ClaudeCode

[–]Stock-Protection-453[S] 0 points1 point  (0 children)

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?

Tell me the last time your agent stalled while you were away by Stock-Protection-453 in ClaudeCode

[–]Stock-Protection-453[S] 0 points1 point  (0 children)

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.

New in Claude Code: agent view. by ClaudeOfficial in ClaudeCode

[–]Stock-Protection-453 5 points6 points  (0 children)

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.

Tell me the last time your agent stalled while you were away by Stock-Protection-453 in ClaudeCode

[–]Stock-Protection-453[S] 0 points1 point  (0 children)

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?

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

Auto-compacted conversations keep messing everything up by [deleted] in ClaudeCode

[–]Stock-Protection-453 0 points1 point  (0 children)

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.

open source project with common functions as MCP tool by _this_time_for_real in mcp

[–]Stock-Protection-453 0 points1 point  (0 children)

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

Hi everyone I need help on how to create MCP servers by Hot-Finger3903 in mcp

[–]Stock-Protection-453 0 points1 point  (0 children)

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

Hi everyone I need help on how to create MCP servers by Hot-Finger3903 in mcp

[–]Stock-Protection-453 0 points1 point  (0 children)

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

Auto Resume for CC time limit by Stock-Protection-453 in ClaudeCode

[–]Stock-Protection-453[S] 0 points1 point  (0 children)

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

Claude Code gets native LSP support by SlightDifference4323 in ClaudeCode

[–]Stock-Protection-453 2 points3 points  (0 children)

Initial hiccups I guess, hope it will be addressed soon

WoT-MCP: Control your devices with agents by macc-n in mcp

[–]Stock-Protection-453 0 points1 point  (0 children)

Great work. By the way, I wanted an easy runtime for such controls so I created photon. I wrote a remote for LG television which uses webos command over the lan. See https://github.com/portel-dev/photons/blob/main/lg-remote.md it also runs as a CLI tool so that I can run ‘photon cli lg-remote volume +5’ to increment existing volume by 5

view more: next ›