Safety and sandboxes

Neondeck does not use one universal sandbox. It gives each kind of work a different combination of workspace access and product capabilities. Ordinary conversation starts in a virtual scratch workspace. PR review gets bounded, read-only access to one revision. Watched-PR Autopilot can receive a trusted local coding workspace. Direct host commands go through a separate policy and approval system.

The most important distinction is that a model workspace and permission to cause an effect are separate. A virtual workspace prevents direct browsing of the host filesystem, but a schema-checked Neondeck capability may still read a registered repo, update local state, call GitHub, or use a connected service. Conversely, an Autopilot owner can have a real shell while still lacking the capability needed to push or respond to a PR.

flowchart TB Request["You, a schedule, or a GitHub change"] --> Route{"What kind of work is it?"} Route --> Chat["Chat or scheduled instruction virtual workspace"] Route --> Watch["PR watch deterministic read-only poller"] Route --> Review["Human PR review exact-revision reader"] Chat --> Capabilities["Bounded Neondeck capabilities"] Capabilities --> State["Local state, registered repos, GitHub, and connected services"] Capabilities --> CommandGate["Host-command policy allow, ask, or deny"] CommandGate --> Host["Local host or experimental exe.dev command path"] Watch --> Delta{"Meaningful change?"} Delta -->|No| Quiet["Stay quiet"] Delta -->|Yes, fixing mode| Owner["Trusted coding owner managed worktree"] Owner --> Delivery["Mode-bound push and response checks"] Review --> Findings["Local briefing and draft findings"] Findings --> Human["Human reviews and submits"]

Boundaries at a glance

Surface	Workspace	Effects it can cause	Primary boundary
Plain chat	Virtual scratch space	Typed reads and mutations for registered repos, local state, GitHub, and connected services	Capability schemas, repo boundaries, policy, and confirmations
Scheduled instruction	Virtual scratch space	The same bounded product capabilities, subject to scheduled-origin restrictions and existing approval policy	Durable task claim, bounded run, capability policy, and audit
PR watch	None while polling	Read GitHub state and update local watch state	Deterministic change detection and quiet no-op behavior
Autopilot fixing turn	Trusted host shell in a managed worktree	Edit, validate, and commit; push or respond only in eligible modes	Worktree binding plus mode-scoped delivery capabilities
Human PR review	Read-only view of one exact revision	Create a local briefing and draft findings	Revision binding, bounded reads, and human-owned submission

Plain chat

A normal Neon conversation uses an in-memory workspace. Files placed there are temporary and it is not a mounted view of your machine or registered repositories. Neon cannot use generic shell or filesystem tools to wander through the host from this workspace.

Useful work happens through explicit Neondeck capabilities. Repository operations resolve a registered repo or managed worktree, require repository-relative paths, reject traversal and symlink escapes, and apply sensitive-path, stale-write, lock, and audit checks. Routine edits do not create host-command approvals because repository editing is its own bounded capability rather than arbitrary shell execution.

An interactive conversation can prepare a managed worktree, edit it, commit it, and—when it is linked to a current PR head—request a guarded push. Pushes are non-force, destination-bound, and may require a fresh confirmation when the effect expands beyond the normal interactive guardrails. The confirmation is tied to the reviewed commit and effect; changing the worktree invalidates it.

This means “virtual workspace” does not mean “incapable of changing anything.” It means host access is mediated by product capabilities whose scope and result can be checked.

Scheduled tasks and briefings

The scheduler first claims each due occurrence, prevents overlapping scheduler ticks, and records an independent run. A general scheduled instruction normally receives a fresh bounded agent conversation. It may instead target an existing Neon session when conversation continuity is explicitly useful.

Scheduled model work uses the same virtual workspace as chat. Selecting a repo or working directory supplies task context; it does not mount that directory or grant a generic host shell. Any real repo, service, or command access still goes through the corresponding Neondeck capability.

The default fresh-session target cannot use the ordinary interactive commit and push path. It can still use other typed capabilities allowed by the task. If you deliberately target an existing agent session for continuity, the turn inherits that session's interactive context, including any linked repo or worktree authority. A scheduled instruction should therefore be treated as automation—not as a read-only reminder. Destructive configuration changes retain their confirmation requirements, connected-service calls retain their own allow, ask, or deny policy, and a host command marked as unattended must be preapproved.

Briefings are narrower than general scheduled instructions. They are told to summarize a persisted fact snapshot, use relevant approved data sources, report partial coverage honestly, and avoid external mutations. They run in a dedicated briefing conversation so a background result does not replace the active chat.

Watched repositories and Autopilot

A PR watch is deterministic and read-only by default. It polls structured GitHub state, compares that state with durable watermarks, and stays quiet when nothing meaningful changed. Merely watching a PR does not create a coding workspace or start a model turn.

When an actionable change reaches a fixing mode, Neondeck creates or reuses one managed worktree and one continuing owner for that PR. The owner receives a real local shell with the repository toolchain. Commands have a maximum runtime, but they do not pass through the ordinary per-command approval list. This is intentional: the selected Autopilot mode authorizes repository-native coding and validation inside that trusted workspace.

Neondeck gives the owner a private home directory and removes the usual GitHub token, SSH agent, credential helper, and interactive credential paths from its shell environment. Workspace commands therefore should not be able to deliver changes accidentally. Push and PR-response authority arrives through separate capabilities selected from the current mode and turn source:

Notify only never starts a coding turn.
Prepare only may edit, validate, and commit locally, but cannot push or respond.
Fix with approval prepares the commit first. Push and response are available only during the exact current reviewed-revision approval turn created through Active Watches or the typed API. Generic owner follow-ups can request work but cannot approve delivery.
Push when safe lets a watcher-generated turn push and respond after the owner judges the change sound and the final destination, identity, permissions, exact PR head, clean commit, and non-force race checks all pass.

A mode change takes effect at the capability boundary, not just in prompt text. If authority, credentials, PR head, worktree state, or delivery facts become uncertain, Neondeck retains the local commit and blocks delivery for human inspection.

Important local-workspace limitation

The current Autopilot coding workspace is a trusted host workspace, not a container, virtual machine, chroot, or adversarial filesystem jail. Neondeck starts the owner in its managed worktree and instructs it to stay there, while bound repository and delivery operations validate that worktree. The underlying shell still runs as the Neondeck server user and should be treated as having host visibility. Use higher-authority Autopilot modes only for repositories, models, prompts, and local machines you trust.

Reviewing a PR for a human

PR review uses a separate read-only model role. It has no generic shell, no generic filesystem tools, no repo mutation capabilities, and no GitHub delivery capability. Neondeck supplies bounded PR facts and, when the repo is registered locally, read-only tools that list, search, and read files at the exact reviewed commit and compare that revision with its merge base.

Exploration has a fixed call budget and bounded file windows. Large, binary, generated, unavailable, or truncated changes may therefore require manual inspection. Findings that cannot be proven against an exact changed line remain report-only instead of being attached to a guessed location.

The review run may persist a local briefing and seed local draft comments. It never submits a GitHub review. Follow-up reviewer chat stays bound to the saved head revision and has the same read-only limits. A human owns editing drafts, choosing a verdict, replying to threads, and submitting the final review from the dashboard.

Direct host commands

Arbitrary command execution is separate from repo editing and Autopilot. The default policy enables local execution with manual approval. A small set of read-only diagnostic commands is preapproved; other interactive commands create an approval request. Approval can be one-time, session-scoped, or promoted to a persistent command rule. The model cannot approve its own request.

The local backend runs directly on the host in the requested existing directory. It accepts one executable plus arguments rather than a shell pipeline, receives a reduced environment, has a ten-minute maximum runtime, and stores bounded output previews. Broad destructive patterns such as system erasure, device formatting, shutdown, and process-wide termination are always blocked, even when approvals are disabled.

Experimental: exe.dev command backend

Work in progress: the exe.dev integration is not a remote Neondeck workspace and is unlikely to behave as users expect from a general sandbox setting today. Enabling it does not move chat, scheduled tasks, PR review, managed worktrees, or watched-PR Autopilot onto the VM. Autopilot continues to edit, validate, commit, and push from its local managed worktree.

The implemented portion can run one approved command over SSH on an existing VM. It can also create a remote checkout from a GitHub-reachable revision and forward explicitly selected environment values. It does not copy uncommitted local work, provide seamless local-to-remote workspace continuity, or create and dispose VMs for each task. Treat it as an experimental diagnostic path, not a safety boundary for autonomous coding.

What is audited

Neondeck keeps durable records for scheduled occurrences, agent submissions, app operations, watch changes, worktree events, repo edits, execution decisions, command outcomes, connected-service approvals, and Autopilot delivery. Review briefings and draft findings remain local until a human submits them.

Audit data is sensitive. It may include prompts, command arguments, bounded output, file paths, diffs, tool arguments, and model responses. Keep the dashboard, runtime state, and raw run inspection available only to trusted local users.

Current limitations

Local command execution and the Autopilot coding shell are host processes, not OS-level isolation.
The virtual chat workspace limits direct filesystem access, but typed product capabilities can intentionally cross into registered repos, local state, GitHub, and connected services.
Destructive-command detection and output redaction are defense in depth, not a complete shell security system or general-purpose secret scanner. Treat every preapproval as delegated trust.
Scheduled instructions are bounded runs, not automatically read-only runs. Keep their requested effects narrow and review their history.
PR review is revision-bound and evidence-bounded; it can miss issues outside the supplied facts or exploration budget.
exe.dev support is work in progress. Only explicit approved commands and GitHub-reachable checkouts can use an existing VM; the main agent workspace and managed worktrees remain local.