Use the launch directory for REPL work and contain Sidekick file access #1113

Story

As a person launching xmd repl from a project directory, I want Sidekick and entries to work in that launch directory, with Sidekick's XMD file operations limited to that directory and descendants, so relative paths match my terminal and Sidekick cannot use ordinary file operations to browse the broader filesystem.

The user requests four connected outcomes: align the initial cwd, contain Sidekick XMD file operations, expose the current directory through Cwd, and teach output capture. The user explicitly clarified that the new filesystem restriction applies only to Sidekick's XMD file operations, not to shell commands or agents it launches. This is not an OS/process sandbox story.

Current behavior and verified evidence

At inspected main 5de2b09ea6f53eaed1d1af2a8ddc34e43c8c7ea8, Sidekick owner opens its conversation under input.workspace. REPL entry preflight and execution choose the session workspace for Sidekick submissions and projectCwd for manual entries. The environment/entry guides teach this distinction. The requested default therefore deliberately changes the earlier #975 workspace-cwd direction; it is not just an accidental spelling of pwd.

A local installed-XMD0.14.0 probe launched from a project directory executed a document located in a different directory. Ordinary xmd run shell pwd returned the launch directory, and a direct nested Dir returned its child directory. A Markdown wrapper placing Content inside that Dir returned the outer directory instead. The latter is the existing #985 projection defect and affects run as well as REPL.

The installed build's xmd syntax Cwd refuses because Cwd is not available. Source inspection found no corresponding built-in component.

A separate local probe verified existing capture behavior: a shell fence sh exec as="commandResult" binds exitCode7, stdout and stderr separately, and a text component with as="componentOutput" captures its rendered text. The shipped Sidekick guides explain general captures and entry reads but lack a complete shell-result/stdout example.

Reproduction sources are local supervisor fixtures cwd-audit/documents/probe.xmd, capture.xmd and the small project components. They use no model calls, external files or secrets. The Sidekick containment requirement still needs an explicit production-host boundary probe; source cwd selection alone proves no containment guarantee.

Accepted outcomes

1. Fresh Sidekick evaluation and both manual and Sidekick-submitted entries start from the directory where XMD was launched. Use the existing scoped contextual cwd API; nested Dir changes the current cwd for its body and restores it on exit. Session storage and execution cwd are separate concepts.
2. Sidekick's XMD file operations can access the authorized entry/project cwd and descendants recursively, and cannot reach parent or sibling directories or arbitrary absolute host paths. Apply the boundary at the actual host file-operation owner, including canonical path/symlink escape handling, read/write/delete/enumeration/directory operations that the surface exposes, rather than relying on prompt instructions. Do not misrepresent the requested XMD-only boundary as containment of shell commands, native agents, trusted plugins or arbitrary host code.
3. Add or expose a read-only Cwd component reporting the execution's actual current contextual cwd, including nested Dir and restored outer scope. Document its normal return/capture behavior and make syntax discovery, entry execution and eligible Sidekick use agree. Reading cwd grants no filesystem authority.
4. Teach Sidekick, with complete executable examples, how to capture a shell command's stdout, stderr and exitCode; capture rendered component output; and submit an entry then read its exact output through REPL.Entry.Output. Keep Sidekick-response syntax distinct from entry syntax. Reuse existing capture forms rather than creating another output API. Large output follows temporary Store unchanged large binding values once in xmd repl histories #999 file-reference guidance.

Journals remain host-owned session data, and history inspection/recovery keep their existing trusted owners. A starting cwd is not a grant to browse private session storage. Before implementation, settle how automatic session-component discovery, component authoring, generated artifacts, explicit imports/mounts and reopening compose with the requested cwd and access boundary. Preserve acknowledged history and identities; changing a new default does not authorize replay or wholesale rebinding of active sessions.

Verification and delivery

Use distinct project, session-storage and sibling canary directories so tests cannot pass because their paths coincide. Check initial pwd for run, manual REPL entry, Sidekick response and Sidekick submission; nested Dir and Content projection; scope cleanup on failure/cancellation; and cold-reopen behavior under the explicitly settled contract.

For Sidekick XMD operations, witness allowed descendant access and refusal for parent/sibling/absolute and symlink escapes, leaving the outside canary unchanged. Keep operation permissions and contextual middleware composition intact. Test component discovery and journals through their trusted host owners separately.

Execute the guidance examples against actual supported entry/response contexts and assert the exact command result and entry/component output. Verify Cwd at root and inside a nested Dir with matching shell pwd where the host permits commands.

Left owns #985 and its in-flight source changes. Finish or join that owner and coordinate shared boundaries; do not silently expand its current accepted plan. Deliver this new launch-cwd/access/component/guidance work as a separately planned and reviewed PR. No existing REPL restart, candidate workflow hotload or broader #1101 rollout is authorized by this issue.

Relationships

• Preserve <Dir> working directory through <Content /> #985: preserve Dir cwd through Content; existing defect already reproduced in run.
• Use each xmd repl session directory as its workspace #975: earlier session-workspace default intentionally amended by this new user direction; keep useful session storage/discovery behavior through an explicit revised contract.
• Store unchanged large binding values once in xmd repl histories #999: safe large-binding storage and removal of temporary guidance remain separate.
• Diagnose and reduce oversized adversarial workflow handoffs #1112: workflow handoff-size diagnosis/reduction remains separate.

User decision: session-owned assets

The user rejected placing newly imported files in the launch project's inputs directory and explicitly chose the name assets instead of inputs. Newly approved imports belong in assets/ under the session directory. The execution cwd remains the launch directory; storage location and cwd are distinct.

Preserve existing imported copies and acknowledged history without silently relocating them. Keep per-asset approval and occupied-destination refusal. Provide an explicit supported way to reference approved session-owned assets from launch-directory entries and Sidekick XMD without granting access to unrelated private session data or the broader filesystem. The Planner must account for this deliberate exception at the host-owned asset boundary; ordinary cwd containment is not permission to browse the entire session directory.

This settles the import location/name decision. Any remaining interface decisions are presented one at a time.