← ClaudeAtlas

session-opslisted

Spawning a child session, notifying the human, and what you can and can't do with a dev server/dock from inside a Mullion-hosted session. Read this if you're an agent CLI running inside a Mullion-hosted session and need to fan out work, surface progress, or check on a dev server, in ANY repo.
s3ntin3l8/mullion-session-manager · ★ 0 · AI & Automation · score 56
Install: claude install-skill s3ntin3l8/mullion-session-manager
# Mullion session ops Check for `$MULLION_SESSION_ID` before following anything below — if it's unset, you're not inside a Mullion-hosted session and none of this applies. ## Spawning a child session `spawn_child_session` (MCP) / `mullion session spawn-child --command <cmd>` (CLI) is reachable at session scope — it spawns a real child session (its own PTY, own terminal) of the session you're running inside, in the same project. You never need to name a project or your own session id; both are derived automatically. A hard cap on live children applies (ask a human to raise `settings.sessions.maxChildSessionsPerParent` if you hit it); `cwd`, if overridden, must stay inside the project directory. This is a genuine child session — it survives if you're later killed, not a `Task`-tool subagent (no session, no PTY). A spawned child always starts as an ordinary, visible `terminal` session with permission prompts on; `kind` and `skipPermissions` are silently ignored from inside a session even if you pass them (only a full-scope operator can set either). Its panel doesn't auto-open unless a human turned that on separately — either way it shows in the sidebar. ## Notifying the human ```bash mullion notify --message "..." [--title "..."] ``` Writes straight to the hook socket, bypassing the control socket entirely — surfaces in the notification bell/desktop-notify, same as a terminal BEL. Only works from inside a session, and can't target a different one. Use this to surface prog