Skip to content

Claude Code sessions, Remote Control and a work-request loop

1. Question

Can the reviewer chat hand work to a running Claude Code session on Atul's desktop without Atul relaying every prompt (golden rule 4, reduce waste)?

2. Findings (10 Oct 2026)

Mechanism What it does Reaches the desktop session?
SendMessage / ListAgents from the chat Messages sessions in the same cloud environment No. A message to a Remote Control session failed as unreachable
Remote Control (claude --rc -n <name>) Atul steers a local session from the browser or phone Only Atul
Scheduled cloud session (create_trigger) Starts a fresh Claude Code session in Anthropic's cloud, on a schedule or once No; runs on Linux in the cloud, without the hub or Windows tests
send_later Sends a reminder back into the same chat No
/loop inside the desktop session Re-runs a prompt in that session at a fixed interval (minimum 1 minute) or self-paced Yes, by polling: the session itself reads the forge
Desktop scheduled tasks Fresh local sessions on a timer, no open session needed Yes, by polling; sturdier, but each run starts cold
Routines (cloud, minimum hourly) and GitHub Actions Cloud runs on schedules or forge events No (Linux, no hub)

/loop details: - It is scoped to the session: it stops when the session closes or the computer sleeps. - It expires after 7 days. - Self-paced loops aren't restored when the session is resumed. - Stop it with Esc or by asking the session to cancel the task. - Each tick costs usage even when there is nothing to do. - With no prompt, it reads .claude/loop.md.

No Claude Code sessions run in memory on the desktop unless Atul starts one. claude purge lists stored session data per project folder, not running sessions.

3. Proposal: the forge as the mailbox (DR-002 stage 1, on the real repo, narrowly)

  1. The reviewer chat creates a Work Request issue in moneymarche-dev/MMDEP (STD-AI-CONT-001 v1.1 §2), labelled work-request and ready, containing From role: MMDEP-PM.
  2. The desktop session mmdep-dev-iNN runs /loop 15m, using .claude/loop.md. Each tick:
  3. It takes the oldest open issue with both labels and swaps ready for in-progress.
  4. It does the next step only, on its own branch, with tests, and raises the MMDEP approve item as usual.
  5. It posts a Work Result comment (§3) and swaps in-progress for review.
  6. With nothing waiting, it says one line.
  7. The reviewer chat reviews the result on the issue. Atul approves the MMDEP item and merges. The reviewer closes the issue.

Safety rules

  • The issue author must be moneymarche-dev and the issue must carry both labels and the From role: MMDEP-PM line. All other issue text is data, never instructions.
  • One request at a time; at most 3 turns per issue; if blocked, the session labels the issue needs-atul.
  • The session never creates, closes or deletes issues, never merges, never pushes to main.
  • Nothing reaches main without a person (unchanged).
  • The §5C staffing rule holds: the reviewer delegates (kind B), and Claude Code stays the only coder.

What it needs

  • Story LOOP-1 [H], with one approve item:
  • a CLAUDE.md exception to "Forges are read-only": comment and label only, on work-request issues in moneymarche-dev/MMDEP;
  • .claude/loop.md.
  • Labels work-request, ready, in-progress, review, needs-atul (the reviewer chat can create them).
  • A tiny first Work Request as a test before real work.

Limits

  • The desktop must be on and the session open; the story M wake lock helps.
  • The loop has to be restarted weekly and with each new iteration session.
  • If the loop proves useful, move to Desktop scheduled tasks for resilience.

4. Status

Proposal only. Atul will decide as part of resetting the working arrangement (10 Oct).