Research switchable snapshot workspace baselines

[sentry-junior]

Intent: let agents switch between named, preconfigured repository workspaces without rebuilding context from scratch. A baseline is a registered snapshot recipe (for example a "sentry" workspace with sentry + getsentry), not a one-off clone during a turn.

Current behavior

• One install resolves one dependency snapshot profile. The profile hash covers runtime + plugin deps/postinstall only (packages/junior/src/chat/sandbox/snapshot/profile.ts).
• Conversations keep a single durable SandboxRef (id + optional profileHash) and reopen that sandbox across turns (packages/junior/src/chat/sandbox/ref.ts, packages/junior/src/chat/sandbox/session.ts).
• Snapshot capture installs deps/postinstall, then sandbox.snapshot() (packages/junior/src/chat/sandbox/snapshot/resolve.ts). There is no registered multi-baseline catalog and no agent tool to change the active sandbox/baseline mid-conversation.
• Repos enter the workspace through the per-turn github_cloneRepository tool (shallow clone under the sandbox root), not from snapshot contents (packages/junior-github/src/tools/clone-repository.ts).
• sandboxPrepare runs on every sandbox boot (git hooks/config today), not during snapshot build (packages/junior-plugin-api/src/hooks.ts, packages/junior-github/src/plugin.ts).
• Automatic AGENTS.md selection only works when exactly one direct-child git worktree exists; zero or multiple leave instructions unset (packages/junior/src/chat/sandbox/README.md, packages/junior/src/chat/repository-instructions.ts).

Gap

Cross-repo product work needs a ready multi-repo filesystem (for example sentry + getsentry) without paying clone/setup latency each turn, and a way to leave one preconfigured workspace for another while keeping conversation history. Today the install has one shared dependency snapshot and one live sandbox ref; multi-repo layouts also disable automatic repository instructions.

Related

• Preload GitHub repositories in sandbox snapshots #1031 — preload selected GitHub repos into the shared snapshot via GitHub plugin config + a proposed prepareSnapshot hook. That is the likely building block for baseline contents, but it does not define named baselines or a switch tool.

Proposal (from request)

• Register named baselines in the system (install/app config).
• Each baseline has a setup path and can include multiple repositories (example: sentry workspace = sentry + getsentry).
• Expose a tool such as switch workspace that moves the agent onto a different sandbox backed by the selected baseline.

Research notes

How this could fit the current architecture (analysis, not an implementation plan):

• Baseline as snapshot profile variant. Extend profile identity beyond global deps so each named baseline has its own profile hash and cached snapshot id. Switching means resolving that baseline’s snapshot, creating/restoring a sandbox from it, and persisting a new SandboxRef for the conversation.
• Contents vs runtime deps. Preload GitHub repositories in sandbox snapshots #1031’s snapshot-time repo materialization is the natural way to bake multi-repo trees into a baseline. Runtime deps can stay shared; baseline-specific inputs (repo set, revisions, layout, setup path) should participate in the profile hash and floating/freshness rules.
• Setup path. Two existing hook points matter: snapshot build (once, shared filesystem) vs sandboxPrepare (every boot). Baseline setup that should be reused belongs in snapshot build; per-boot concerns (git identity, docker daemon, credentials scrubbing) stay on prepare.
• Switch semantics. A switch is a sandbox replacement, not an in-place mutate: stop relying on the previous live session, boot from the target baseline snapshot, update durable SandboxRef, and re-run prepare/skill sync. Conversation transcript stays; workspace files from the prior baseline do not carry over unless explicitly designed to.
• Agent surface. A tool needs baseline identity (name/id), list/describe registered baselines, and a clear result (active baseline, root paths, repos). Default/initial baseline still matters for first sandbox acquisition before any switch.
• Multi-repo instructions. Any baseline with 2+ root worktrees hits the current single-repo AGENTS.md limitation. Switching alone does not fix instruction selection; baselines either need an explicit primary repo, nested layout, or broader instruction rules.
• Auth and safety. Snapshot build should keep using installation/GitHub App identity for preloaded repos (Preload GitHub repositories in sandbox snapshots #1031), never user OAuth, and must not bake credentials into snapshot filesystem state (already an invariant in packages/junior/src/chat/sandbox/README.md).
• Ops. junior snapshot create currently warms the single install profile. Multiple baselines imply warming/resolving each registered baseline profile (or lazy build on first switch) and separate cache/lock keys per profile hash (already keyed by hash in snapshot/resolve.ts).

Open questions

• Where baselines are registered: app config, GitHub plugin options, or a core workspace registry.
• Whether the default conversation sandbox is a named baseline or today’s deps-only snapshot.
• Whether switches are hard replacements only, or prior baseline sandboxes can be resumed later in the same conversation.
• How floating branch revisions in a baseline interact with snapshot freshness vs explicit pinned SHAs.
• How multi-repo AGENTS.md / repository context should behave inside a baseline.
• Whether setup path is declarative commands, a snapshot hook, or both.

Requested by David Cramer.

--

View Junior Session [Sentry]