Download packages/daemon/specs/agents/shared/skills/core/session-source-fork/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does session-source-fork live?
The publisher keeps it at https://github.com/mvschwarz/openrig.
Which agents can use session-source-fork?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.
|
name: session-source-fork
description: |
Use when authoring a rig spec member or rig expand payload that needs to start a new managed seat from a prior runtime conversation source — session_source: { mode: fork, ref: { kind, value } }. v1 supports mode: fork with ref.kind: native_id for Claude and Codex. The new seat persists a NEW post-fork token; the parent token is NEVER written onto the new seat. NOT for restoring an existing seat or for artifact-backed mental-model rebuild.
metadata:
openrig:
stage: factory-approved
sibling_skills:
- claude-compaction-restore
- session-compaction-and-restore
- agent-startup-and-context-ingestion
- agent-starters
- seat-continuity-and-handover
session_source Fork
session_source is a member-level OpenRig field that declares how a
newly-launched managed seat should derive its initial conversation
continuity from a prior runtime conversation source.
v1 supports one mode: fork — start a new managed seat from a
prior native runtime conversation source without claiming the original
seat continued.
The schema is runtime-neutral; implementation is runtime-specific (Claude
and Codex have their own native fork commands).
Use this when
Authoring a rig spec member that should fork from a prior session
Authoring a rig expand payload with session_source
Reasoning about whether to use fork vs rebuild vs resume vs fresh for a new seat
Composing fork + handover (seat-handover-over-fork) — see seat-continuity-and-handover skill
Don't use this when
The seat is being restored, not created. Restore continues an existing managed seat. Fork creates a new seat.
The continuity is artifact-backed mental-model rebuild (packet-derived understanding, not native runtime continuity). Use mode: rebuild (see seat-continuity-and-handover for the rebuild surface) — do NOT collapse fork into artifact-backed reentry; the distinction is load-bearing.
The runtime is terminal. Terminal runtime rejects session_source.
The shape (canonical YAML)
members:
- id: reviewer-2
runtime: claude-code # or "codex"; not valid on terminal
agent_ref: specs/agents/reviewer.yaml
profile: reviewer
cwd: .
session_source:
mode: fork
ref:
kind: native_id # v1 fork mode supports native_id only
value: "0b0165d7-cb4d-4650-90de-15c0a1ede9e6"
Rules:
mode v1 only valid value: fork.
ref.kind v1 supports native_id only. Schema rejects artifact_path, name, last, and artifact_set pre-launch with explicit deferred/weaker/wrong-mode error messages (see packages/daemon/src/domain/rigspec-schema.ts validateSessionSourceFork). Adapter-level refusal exists as defensive handling but should not be reachable in v1 because schema rejects first.
value required for ref.kind: native_id in v1 (the only schema-accepted kind). Future-state value semantics for artifact_path / name / last are not active in v1 because schema rejects those kinds pre-launch.
rig expand accepts the same shape so dynamically-added members can carry session-source attribution.
The primitive does NOT introduce a new top-level command. It flows
through existing rig spec and expansion pathways.
State model
session_source is a launch-time input, not a long-lived stateful field:
Declared — present in member config or expansion payload
Resolved — at launch time, OpenRig resolves the ref against the runtime
Realized — runtime fork succeeds; new managed seat receives a NEW native continuity token (Claude session id or Codex thread id). OpenRig persists that NEW token. Parent token is NEVER written onto the new seat.
Failed — resolution or fork failed; seat not launched as a fork; clear error names the resolution step that failed
Once realized, session_source is essentially history. Restoring the
seat later is restore of the new seat, not re-fork-from-parent.
Failure modes (5)
Source session id not found — runtime cannot resolve native_id. Action: emit error naming runtime + missing id; do NOT silently launch fresh. (Future-state note: when artifact_path is supported in a follow-up slice, it could become a candidate fallback for Claude; in v1 schema rejects artifact_path pre-launch so no fallback path exists.)
Source artifact path missing(out of v1 scope) — would apply once ref.kind: artifact_path becomes schema-accepted. v1 schema rejects this kind pre-launch.
Unsupported runtime/kind combination(largely pre-empted in v1 by schema rejection) — schema rejects all non-native_id kinds upfront. Adapter-level refusal exists as defensive handling but is not reached in v1.
Fork launch failed after source resolution — runtime command (claude --resume <parent> --fork-session or codex fork <id>) returned non-zero or hung. Preserve runtime stderr; do not record new seat as launched; do not write parent token onto seat.
Persistence inconsistency — fork succeeded but seat-token persistence cannot record new continuity token. Internal failure: seat is not considered launched until new token is durably written.
Honest UX rule (verbatim)
The primitive must NOT report "restored the original agent" or "resumed
the original seat" or "snapshot." The correct framing is "forked from
source session" / "started from prior conversation source."
Check the actual user-facing outcome and persisted identity; wording alone
does not prove the intended continuity was created.
Hard boundaries (do-not list; verbatim)
Do NOT introduce a DIVERGENT fork primitive. The primitive flows through existing spec/expansion pathways. (Update 2026-08-07: rig fork <source-session> has since shipped as a thin convenience verb that COMPOSES the existing agent-image fork path — this honors the boundary; it is not a divergent primitive. The rule now reads: no NEW fork mechanics outside the spec / expansion / agent-image pathways.)
Do NOT report "restored" / "resumed the original seat" / "snapshot" in any UX surface.
Do NOT couple session_source to AgentSpec. It's a member-level launch-time input.
Do NOT change restore semantics.session_source creates a seat; restore continues an existing managed seat.
Adapter command shape (shipped v1)
Runtime
Command shape
Claude (mode: fork + ref.kind: native_id)
claude --resume <parent-id> --fork-session
Codex (mode: fork + ref.kind: native_id)
codex... fork <parent-id>
Terminal
Rejected at schema level
Mutual exclusion between resumeToken (restore path) and forkSource
(fork path) is enforced at three layers in the daemon.
Continuity outcome literals
Outcome
When
forked
Fork succeeded; new seat has new native token; parent never written onto new seat
fresh
Fresh launch (no session_source declared)
resumed
Restore of existing managed seat
failed
Resolution or fork failed
For seat handover over fork composition, the binding outcome is
independent (see seat-continuity-and-handover skill).
Verify the running implementation
A source checkout and the running daemon can contain different implementations.
Before an authorized fork, check the target daemon's build identity and support
for the requested source. A source or isolated test establishes only that cut's
behavior; it does not prove the live runtime uses it.
Record the actual parent history, new seat identity, new continuity token and
independent binding outcome. Preserve errors and incomplete results rather than
reporting a fresh launch or restored original seat as a successful fork. These
checks confer no authority to launch, replace or retire a live seat.
Currently shipped (v1) vs deferred
Shipped at openrig c7b6df1 (2026-04-30):
Schema accept/reject for full Honest Refusal Matrix
Download packages/daemon/specs/agents/shared/skills/core/session-source-fork/SKILL.md from the publisher, or copy the path and open the repository. PlugMCP lists the skill and does not host the file.
Where does session-source-fork live?
The publisher keeps it at https://github.com/mvschwarz/openrig.
Which agents can use session-source-fork?
Claude, Cursor, and Codex can read a SKILL.md you add from the publisher's repository.