Struct SessionWire 

pub struct SessionWire {

    pub slot: SessionSlot,
    pub state: SessionStateWire,
    pub composer: ComposerWire,
    pub header: SessionHeaderWire,
    pub mcp: Option<McpServers>,
    pub processes: Option<ProcessSnapshot>,
    pub background_tasks: Vec<BackgroundTask>,
    pub monitors: Vec<MonitorRecord>,
    pub terminal: Option<TerminalSummary>,
    pub pending_ask: Option<PendingAskWire>,
    pub pending_asks: Vec<PendingAskWire>,
    pub conversation: ConversationWire,
    pub slash_commands: Vec<AvailableCommand>,
    pub subagents: Vec<AvailableAgent>,
    pub subagent_instances: Vec<SubagentCard>,
    pub file_index: Arc<FileIndex>,
    pub resume_sessions: Vec<ResumableSessionWire>,
    pub reviews: ReviewsWire,
    pub tree_reviews: ReviewsWire,
    pub work: WorkState,
    pub git: GitWorkView,
    pub pr: Option<GitPrInfo>,
    pub closes: Vec<GitIssueRef>,
    pub diff: DiffContent,
}

One session, as a client sees it: every read a session-scoped view makes.

Fields

slot: SessionSlot

state: SessionStateWire

composer: ComposerWire

What this seat’s composer is doing, which no record answered before.

header: SessionHeaderWire

mcp: Option<McpServers>

processes: Option<ProcessSnapshot>

background_tasks: Vec<BackgroundTask>

The seat’s live tasks, which the processes feed leads its rows with: the CLI’s background registry plus the long foreground calls it is tracking while they run, each saying which it is (is_backgrounded).

The tasks the OS walk cannot see for itself are the ones this exists for: a backgrounded bash is setsid-detached, so it sits outside claude’s tree, and a view draws it from the registry - with the command telling it whether the walk has already adopted the process behind one. A foreground call is in the tree already; the row is what names it while it runs.

monitors: Vec<MonitorRecord>

terminal: Option<TerminalSummary>

The seat’s terminal, when it has one: the strip’s row and the state it draws. Absent until the terminal is opened; the strip draws its row for every seat and reads this for the state, so a seat with none draws off and start.

pending_ask: Option<PendingAskWire>

The prompt a one-ask dock draws: the front of pending_asks.

Derived from the same list at serialisation, so the two cannot drift. What a client reading only this draws is the front, which on a mixed set is NOT what the single read answered before the list: that preferred a question over a permission prompt and took same-kind asks in map order, where the front is the oldest ask with a draft leading.

pending_asks: Vec<PendingAskWire>

Every prompt this seat is holding: a draft leads, then arrival order. A parallel batch parks several at once, so a client that attached mid-batch reads the ones behind the front rather than losing all but one.

conversation: ConversationWire

The newest turns, not the whole conversation. See SUBSCRIBE_TURNS.

slash_commands: Vec<AvailableCommand>

subagents: Vec<AvailableAgent>

subagent_instances: Vec<SubagentCard>

The session’s sub-agent instances, as the core joined them: one card per dispatch with its calls under it. The catalogue above names the TYPES the CLI offers; this is what actually ran.

file_index: Arc<FileIndex>

The seat’s own walk, from the store its loop keeps fresh, or a walk taken for the read when the loop has not run. Shared rather than walked per subscriber: the walk is a whole tree. Serialises as the index itself.

resume_sessions: Vec<ResumableSessionWire>

The sessions this seat can jump back to with /resume, newest first.

Carried on the record because the composer’s other sources are: a /resume list is only asked for while a draft’s argument is being typed, and a read on demand would need its own ask, its own answer and a shell command to carry it - the record already reaches every reader the composer draws on. Both a lead’s and a worker’s read is one scan of the directory that seat’s own resume runs in.

reviews: ReviewsWire

tree_reviews: ReviewsWire

The seat-tree review half, beside the branch’s: the files page’s comments, each thread placed against the seat’s working files. Same wire shape as reviews so a page parses one thing; the scope is the seat, not a branch, which is what the files page keys to.

work: WorkState

The working tree behind the git section: the branch, how much has changed, and the gate. The changed files themselves ride diff below.

git: GitWorkView

The tree behind the git row’s depth: the uncommitted files with their marks and counts, the branch’s chain ahead of its default with the commits that produced it, and which branch that is.

What the row above cannot say: a branch and a count tell a reader nothing about WHAT is working, and this is what a hover over the row draws. The content read below carries the same layers with hunks, for the surface that reviews them.

pr: Option<GitPrInfo>

The open pull request this seat’s branch is on, and the issues it closes.

Beside work rather than inside it because the two come from different reads - the branch and the count are the row’s own, and this is the heavier scan - and a client draws the inspector’s GIT section from both. Nothing carried them, so a client would draw the section without the PR #N -> closes #M row a view leads it with.

closes: Vec<GitIssueRef>

diff: DiffContent

The changed files with their raw hunks, bounded and flagged: what a review surface draws a branch from, as data and never as a rendering.

Read beside work rather than pushed with it: the row above moves with the tree, while this is taken once per read that encodes a record - a cold load, a reconnect, a seat swap - the way a view’s /diff scans once on open. Its caps and flags live in forge-agent’s git_diff::content, which is where the read’s shape is decided.

Trait Implementations

impl<'de> Deserialize<'de> for SessionWire

fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>

where __D: Deserializer<'de>,

Deserialize this value from the given Serde deserializer.

impl Serialize for SessionWire

fn serialize<__S>(&self, __serializer: __S) -> Result<__S::Ok, __S::Error>

where __S: Serializer,

Serialize this value into the given Serde serializer.