Sessions

What a session is

A session is a bounded interaction context (session_and_turn_model.md ST-001, §3.1):

• scoped to exactly one operator identity
• scoped to exactly one workspace or project at creation
• bounded by explicit creation and terminal events
• assigned a stable, unforgeable identity at creation
• container for trust state, active permits, active execution envelopes, specialist instances, and accumulated context

A session is not a network connection, not process lifetime, and not model-context-window lifetime. Durable sessions can survive process restarts when state is reconstructable from the audit chain.

v1 deployment note This page describes v1 local-embedded behavior. Team and enterprise deployments use syndicate-server; topology differs, but session identity, lifecycle invariants, and audit-chain lineage requirements remain unchanged.

Session identity

Session identity is a control-plane-minted UUID (v4 or v7) (session_and_turn_model.md §3.2):

• generated by control plane, never by operator or runtime
• recorded in session.created before any turn begins
• never reused after termination

Session lifecycle

State transitions:

Lifetime-immutable bindings (session_and_turn_model.md §3.3):

• operator identity
• workspace path
• initial policy version
• initial trust state binding

Any change to these bindings requires a new session.

Creating sessions

Implicit creation paths:

• bare syndicate
• syndicate run ...

Attach path:

• syndicate --session <id>
• syndicate session attach <id>

Creation requirements (session_and_turn_model.md §4.1):

• operator identity verification
• workspace validation
• policy version resolution
• session ID minting
• durable session.created audit event persistence

If session.created persistence fails, creation fails.

Trust starts untrusted for each new session boundary (session_and_turn_model.md §3.3, governed_execution_spec.md GP-005).

Session commands

syndicate session list

# active and suspended sessions (default)
syndicate session list

# include terminated and expired
syndicate session list --all

# machine-readable output
syndicate session list --output json

Columns: session ID, status, creation time, last activity time, turn count, active specialist count (cli_command_reference.md §5.1).

syndicate session attach <id>

syndicate session attach <session-id>

Attaches TUI to an existing active or suspended session (cli_command_reference.md §5.2).

syndicate session inspect <id>

syndicate session inspect <session-id>
syndicate session inspect <session-id> --output json

Displays session metadata including trust summary, permit count, and turn count (cli_command_reference.md §5.4).

syndicate session export <id>

syndicate session export <session-id> --format ndjson --out session-audit.ndjson
syndicate session export <session-id> --format json

Exports all session audit events as json or ndjson (cli_command_reference.md §5.5).

syndicate session terminate <id>

# with confirmation
syndicate session terminate <session-id>

# skip confirmation
syndicate session terminate <session-id> --force

Termination emits session.terminated, revokes session-scoped specialists, invalidates active permits, and expires active execution envelopes (session_and_turn_model.md §4.4).

Cross-session isolation

Cross-session isolation is a hard boundary (session_and_turn_model.md ST-005):

• state from one session does not flow into another without durable, explicit, policy-governed transfer
• trust does not carry over implicitly
• each session starts from untrusted boundary conditions

Multi-specialist session lineage

When orchestration spawns a specialist, that specialist runs in its own session, linked to parent session lineage (session_and_turn_model.md ST-009).

Constraints:

• child session may not exceed parent capability scope
• child session may not exceed parent trust tier
• delegation boundaries and reasons are captured in evidence

This preserves audit-chain causality and bounded delegation semantics.