> For the complete documentation index, see [llms.txt](https://faction-os.gitbook.io/faction-os-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/phases/phase_06/session_05_isolation_boundary_and_sandbox_diagnostics.md).

# Session 05: Isolation Boundary and Sandbox Diagnostics

**Session ID**: `phase06-session05-isolation-boundary-and-sandbox-diagnostics` **Packages**: apps/server, apps/cli, apps/hooks, packages/protocol **Status**: Not Started **Estimated Tasks**: \~14-22 **Estimated Duration**: 2-4 hours

***

## Objective

Define and expose local isolation boundaries and sandbox diagnostics for future executors while keeping current execution unavailable and non-mutating.

***

## Scope

### In Scope (MVP)

* Create or update the source-backed isolation threat model for local actions, file writes, git operations, terminal commands, Docker or container use, remote execution, and hosted execution.
* Add or refine protocol contracts for sandbox capability posture, unavailable execution reasons, diagnostic summaries, consent requirements, audit requirements, and redaction categories.
* Keep current server route families deterministic: unsupported or unavailable execution must return compact envelopes instead of accidental 404s or half-wired behavior.
* Add server diagnostics for isolation posture that report availability, configuration, counts, and status labels without exposing prompts, command bodies, terminal output, file contents, tokens, broad paths, raw spool data, logs, backups, or state files.
* Update CLI doctor/status output to surface isolation posture and recovery boundaries without performing trusted erasure or mutating valid local state.
* Update hook guidance so future executor signals remain bounded, timeout-safe, and silent unless a later phase deliberately adds execution.
* Add focused tests for diagnostics, unsupported execution, redaction, and no-mutation behavior.

### Out of Scope

* Running file, git, terminal, Docker, remote, or hosted commands.
* Adding a container runtime, remote runner, cloud VM, inbound chat command execution, or hosted queue worker.
* Trusted unified erasure for archives, settings, replay, logs, backups, Worker state, browser hints, or future hosted data.

***

## Prerequisites

* [ ] Session 01 isolation routing and threat baseline are available.
* [ ] Existing local orchestration diagnostics and guarded-action unavailable behavior are reviewed.
* [ ] CLI and hook README files are reviewed before changing user-facing diagnostics.

***

## Deliverables

1. Isolation threat model and sandbox capability posture documentation.
2. Shared protocol contracts or enums for sandbox posture and unavailable execution reasons.
3. Server and CLI diagnostics for isolation posture with redaction and no-mutation guarantees.
4. Tests proving unsupported execution stays deterministic and non-mutating.

***

## Success Criteria

* [ ] Isolation posture is explicit to users and maintainers without implying executors are shipped.
* [ ] Diagnostics expose compact status only and avoid raw local payloads, paths, commands, logs, backups, and state files.
* [ ] Unsupported execution remains deterministic, tested, and documented.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://faction-os.gitbook.io/faction-os-docs/.spec_system/archive/phases/phase_06/session_05_isolation_boundary_and_sandbox_diagnostics.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.