Cloud Spawn — a Worker Session From a Cloud EM

Cloud-only. A cloud EM starts another cloud session with create_session (claude-code-remote MCP). That call works in auto mode. What the classifier refuses is the brief: a prompt telling the child to create triggers aimed at the parent, publish artifacts, or push speculative branches reads as an external write, and the whole spawn is denied. Tripwire: A-SPAWN-BRIEF-THAT-ASKS-FOR-SIDE-CHANNELS-IS-REFUSED-WHOLE.

Children sit behind the same egress proxy: they add build throughput, never publish capability (binary release uploads are refused from cloud). Don't spawn children for publish-bound work.

Spawn it

1. Pick the creation source by the work, never by the tooling. source_url is the child's only work-repo slot: a session created from one repo cannot attach another with push access in auto mode. Name the repo the child must write to. The coordinator plugin and engine arrive on every source; project-rag's red-carpet install is tracked as its own work, so don't pick project-rag as the source just to get its tools.
2. Omit environment_id so the child inherits this environment.
3. Write a narrow brief:
   • Name the parent (CLAUDE_CODE_REMOTE_SESSION_ID) and state the one question.
   • List reads, not writes: shell probes, ToolSearch, get_session, ListAgents, read_documentation.
   • Name exactly one report write: a single comment on this EM's channel PR (coordinator:cloud-channel).
   • Mark untested items UNTESTED and stop.
   • Leave out trigger creation, artifact publishing, extra branches and add_repo grants. If a capability needs one of those tested, ask the user for that one first.
4. Wait for the comment. The channel PR's subscription wakes this EM when the child posts. Never poll get_session on a timer; read it only when the comment is overdue by a real signal.

Why a PR comment on the source repo is the channel

A child cannot reach its parent through ListAgents or SendMessage (separate containers), and get_session is read-only. It can write a PR comment only on a repo in its GitHub scope: its creation source plus add_repo attachments. So the parent's channel PR must live on the child's source repo. coordinator:cloud-channel makes the PR and subscribes to it.

A child's own subagents have no Workflow tool, so fan-out stays with a top-level session.