[FEATURE] Raise, configure or document the lineage depth limit (8) on create_session in cloud sessions

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

In Claude Code on the web, a session can start another session with the create_session tool (Claude Code Remote MCP server). Chains of sessions stop at a hard depth of 8 below the session a person opened by hand:

create_session: caller session is at lineage depth 8 (limit 8); cannot spawn or re-arm further child sessions

The limit is not documented, and I found no setting that changes it: not in the cloud-sessions or routines docs, not among create_session's parameters. The check happens server-side, so nothing in the repo or the environment can raise it.

The case this breaks is a session handing its work to a fresh successor instead of compacting: write a summary, start a new session on the same branch, stop. Each handoff adds a level, so a long-running task dies at the eighth handoff, and only a person opening a new top-level session by hand resets the count. Breadth is fine (a single session started 9 children without complaint); depth is the only thing capped.

Proposed Solution

In order of preference:

1. Don't count a handoff as nesting. When a parent starts a child and then ends (it is idle or archived and never gets another turn), the child replaces it rather than nesting under it, so it could inherit the parent's depth instead of adding one.
2. Make the limit configurable — per account, per organization or per environment — with the default staying at 8.
3. At minimum, document it, next to the other cloud-session limits, and have get_session report the current lineage depth and the limit, so a session can see the wall coming instead of hitting it.

Alternative Solutions

• Flattening the tree: one coordinator session starts every worker, and each worker reports back by creating a one-off trigger (create_trigger with persistent_session_id pointing at the coordinator). This works and keeps depth at 1, but it needs a long-lived coordinator, which a handoff chain exists to avoid.
• Starting a new top-level session by hand whenever the chain nears 8. This works, but it takes a person, which is exactly what the unattended chain was meant to remove.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

1. A long task runs in a cloud session until its context is too big to be useful.
2. Instead of /compact, the session writes a summary to the branch, calls create_session for a successor on the same branch, and stops.
3. The successor carries on and later does the same.
4. At the eighth handoff, create_session refuses, and the work stalls until someone notices and restarts it by hand.

Additional Context

Measured on 2026-09-28: a chain of sessions each creating one child with a decrementing counter; the eighth descendant got the error above. The same session, spawning children side by side, created 9 without a refusal.

---
_Generated by Claude Code_