Run NodeSpace-launched agent sessions in the project's checkout with the session plugin, and delete the context assembler #3547

Overview

An agent session NodeSpace launches should be the same as one a developer starts from their own terminal: same harness, same plugin, same commands, working in the project's code. Today a launched session runs in a private session folder, gets an empty context file, and talks to the wrong database. This issue makes a launched session run in the project's checkout with its environment set, and removes the context file path.

Problem Statement

• It cannot work on the code. A launched session's working directory is ~/.nodespace/agent-sessions/<uuid>/, not the developer's project.
• The context file is empty. The context assembler is built with no seed nodes and nothing ever supplies any, so every launch writes a header and nothing else. A SKILL.md is copied beside it with no frontmatter, where no harness discovers it.
• CLI calls hit the default database. The session's environment is cleared to a short allowlist with no NodeSpace variable, so nodespace commands inside a session launched from another database go to the default one.
• CLAUDE_CONFIG_DIR is dropped, so a user on an alternate Claude profile gets a different configuration inside the session than the installer wrote to.
• Launch can fail after detection passes. Detection searches an augmented PATH; launch resolves the binary on the daemon's own.
• Agent ids disagree. The session service uses antigravity-cli and open-code, the skill installer uses antigravity and opencode, and nodespace session launch advertises ids the daemon rejects.
• The docs describe a design the code does not have: a temp directory disposed on exit, a written tool shim, and a launch that takes a task and seed nodes.

Proposed Solution

• Run in the project's checkout. The launch names a project; the session's working directory is that project's folder on this machine. The folder is a per-machine setting, asked for the first time a session is launched for the project and remembered. It is never shared.
• Set the environment. Pass the database the session was launched from, the daemon socket, and the task or chat node the session was launched for. Forward CLAUDE_CONFIG_DIR when set.
• Let the plugin do the rest. The harness plugin, already installed for terminal sessions, orients the session and, when a task was named, opens with that task's context. No context file and no skill copies are written.
• Report the harness session id. The plugin tells NodeSpace its harness's own session id at session start, because sessions in one project share a working directory and the id can no longer be found by looking for a unique one.
• Delete the context assembler, the context-file choice per agent, and the embedded skill copies.
• Fix the binary resolution and the agent id vocabulary.

Documentation

• ADR-093 §8 - launched sessions: working directory, environment, no context file, session id reporting; §9 - what is removed
• ADR-032 - the PTY session architecture, amended by ADR-093
• ADR-053 - a request targets one database
• ADR-061 - machine-bound properties, for the per-machine folder
• ADR-088 - ai-chat-pty and its fields
• Agent session - the session architecture doc
• Updates: architecture/agent-session.md (rewrite the launch, lifecycle and context sections to what the code does), ADR-032 (mark the context-file, temp-directory and shim provisions as amended by ADR-093), components/node-types.md if the folder is stored as a field

Architecture Impact

Implements ADR-093 §8 and the launched-session part of §9, which amend ADR-032 (decisions/032-pty-agent-session-architecture.md): a session runs in the project's checkout and gets its context through the harness plugin, not a written context file. ADR-093 records the amendment; agent-session.md and ADR-032's own text are corrected in this work.

Acceptance Criteria

Working directory

• A session launched for a project starts with that project's local folder as its working directory
• The first launch for a project with no folder set asks for it in the app, validates that it exists, and remembers it for this machine only; it can be changed in the project's settings
• The folder is never written to a place another machine reads; if it is stored as a field it is a local-only field added through the node type sequence
• A launch with no project keeps working: it runs in a private session folder with the environment set
• nodespace session launch accepts a project and a task

Environment

• The session's environment names the database it was launched from and the daemon socket; a nodespace command run inside a session launched from a non-default database reads that database, and a test proves it
• The environment names the task or chat node the session was launched for
• CLAUDE_CONFIG_DIR is forwarded when set in the daemon's environment
• The environment allowlist stays an allowlist: nothing else from the daemon's environment leaks in

Plugin

• A launched Claude Code session shows the same orientation and skill list as one started from a terminal in the same folder
• When a task was named, the session's first turn has that task's context without the agent asking for it
• The plugin reports the harness's session id to NodeSpace at session start, and the id is stored on the session's chat node as it is today at exit
• Two sessions running at once in one project each end with their own harness session id recorded
• A harness with no plugin still launches in the project folder with the environment set

Removal and fixes

• GraphContextAssembler, the per-agent context-file choice and the embedded SKILL.md and reference copies are deleted, with their wiring in the daemon; nothing writes CLAUDE.md or AGENTS.md at launch
• The harness session id is no longer found by matching a unique working directory
• Launch resolves the agent binary on the same search path detection uses
• One set of agent ids is used by the session service, the skill installer and the CLI; nodespace session launch --help lists only ids the daemon accepts
• The unused resume flag in the agent catalog is removed
• references/cli.md documents the changed session launch, and bun run skill:check passes
• Docs updated as listed under Documentation
• Code passes bun run quality:fix
• Tests pass (bun run test:changed)

Technical Specifications

Reference Files

• packages/agent/src/pty/session.rs - PtySession::launch: session folder, working directory, environment allowlist, binary resolution
• packages/agent/src/pty/manager.rs, packages/agent/src/pty/detection.rs - session registry; detection and its search path
• packages/agent/src/pty/harness_session.rs - finding the harness session id by working directory
• packages/agent/src/agent_catalog/context_assembly.rs, packages/agent/src/agent_catalog/registry.rs - the assembler and the per-agent catalog
• packages/agent/src/agent_types.rs - agent ids
• packages/daemon/src/services/agent_session_service.rs, packages/daemon/src/services/assembly.rs, packages/daemon/src/services/capture_service.rs - launch handler, assembler wiring, end-of-session capture
• packages/proto/proto/agent_session_service.proto - LaunchSession
• packages/cli/src/commands/session.rs - session launch and its help text
• packages/desktop-app/app-lib/src/commands/agent_session.rs, packages/desktop-app/src/lib/components/viewers/ai-chat-pty-session.svelte - the app's launch path and viewer
• packages/skill/src/types.ts, packages/skill/src/agents.ts - the installer's agent ids

Implementation Details

• The CLI already reads its database from NODESPACE_DATABASE and its socket from NODESPACED_SOCKET; pass those, and add one variable for the launched task or node that the plugin reads.
• Name the new variable for what it carries. It must not suggest another product or build.
• Reporting the session id is one more daemon operation with a CLI command the plugin calls; it identifies the session by a value the launch put in the environment.
• Session folders under ~/.nodespace/agent-sessions/ are never deleted today. Launches with a project no longer need one; decide whether launches without a project still create one and say so in the PR.
• End-of-session capture keeps writing the session's status, exit code and transcript settings to the chat node.

Dependencies

• Ship a Claude Code plugin that lists NodeSpace's skills in the session and tracks changes; slim the static skill and remove the tool shims #3545 (the plugin a launched session uses)
• Declare context paths on a schema, derive a node's skills from the node and the queries it matches, and return a versioned context read #3557 (the context read a launched session opens with)
• Run a saved query by id or title, narrow it at run time, negate filters, and filter into link and object values #3554 (running the queue a session is launched for)
• Make spec, plan and decision core types with checklist criteria and seeded rules; remove the installable methodologies #3542 (project and its fields)

Related Issues

• Ship Pi and OpenCode plugins that list NodeSpace's skills in the session, and an instructions block for harnesses without one #3546 (the other harnesses' plugins and the instructions block)

Non-Goals

• Resuming a harness session
• Launching a session from a Play
• Sessions on a machine other than the one running the daemon