Auto mode & trusted workspaces

Kin establishes workspace trust before reading project instructions or configuration and before contacting a model. Auto then runs permitted work with the local authority of the person who launched it.

Trust happens before workspace work

Kin resolves the Git worktree root, or the canonical launch directory outside Git. An untrusted interactive launch offers Trust this workspace, Trust for this launch, or Decline. Decline ends the tool-capable launch. In a local client, the decision names the session folder. If trust covers an enclosing Git root, the explanation also names that wider scope.

Persistent trust binds path and filesystem identity. Replacing the directory invalidates it; malformed or noncanonical rows grant nothing and remain revocable through /grants. Broad roots such as / and home are session-only.

Review an explicit workspace list

A capable local client can present several exact workspaces for one review. Read the complete list and each trust root before accepting. Kin records a separate, individually revocable grant for each listed workspace; portfolio membership itself grants nothing.

Added members and replaced directories need new review. If the list becomes stale, prepare and review it again. Retrying after a lost reply cannot recreate a grant you have since revoked. Manage these grants through /grants, just as for a workspace trusted on its own.

What Auto does

Surface	Auto behavior
Shell/code	Run as the launching account.
File tools	Write inside the workspace or an approved related directory; protected paths still ask.
Structured Git/GitHub	Bounded operations may run; force-with-lease requires fresh review.
MCP	Mutation asks unless explicitly covered by an applicable grant.

++shift+tab++ or /mode switches to Strict for review-first work. Approved Strict commands still run as the same account. Neither mode creates an OS sandbox.

Work across related directories

The root can request request_write_scope for one existing related directory, with an exact path and reason. Approval permits ordinary Auto file writes for this conversation and its children, including retained children. The result supplies that directory’s guidance for subsequent model rounds.

Scopes are conversation-only, limited to 16 active directories, and unavailable during planning. /grants revokes them for subsequent writes. Replacement and symlink escapes invalidate scope; resume needs fresh approval. Protected writes and Strict review remain. Scopes do not load sibling settings or change trust, mode, or shell authority.

Direct execution is an authority decision

Kin and its code can access files, credentials, network, devices, and processes available to the launching account. Use a whole-process boundary when a task must not have that reach. Per-command Seatbelt/bubblewrap expansion is retired.

Protected-write paths

Structured file tools ask before changing Git controls, lockfiles, registry settings, Kin/MCP/tool configuration, shell startup/environment files, or SSH configuration. Matching uses resolved paths. Known secret-file reads are refused. These protections do not prevent equivalent code through an unrestricted shell.

Headless and resume fail closed

Headless and resumed launches cannot create workspace trust. Without an existing valid grant or an explicitly declared external boundary, they exit with a needs-human result before backend/tool work. Establish local trust interactively. Children inherit root authority and cannot open their own trust prompt.

Legacy sandbox requests are cancelled on resume, never converted into trust or automatically executed. Rerun the intended action under current rules.

Safety rails, not containment

Planning, exact approvals, protected file tools, MCP trust, Git checks, and fresh-state confirmations keep review explicit. To prevent access mechanically, withhold or broker it outside the Kin process.

Declaring an external boundary

KIN_TRUSTED_BOUNDARY=container declares that an operator-provisioned container, VM, dedicated account, or equivalent already owns isolation. Kin consumes that declaration instead of prompting for a workspace row; it does not construct or verify isolation. The operator owns mounts, credentials, networking, and lifetime. Ordinary Auto/Strict policy still applies inside it.

Retired sandbox* settings remain temporarily recognized as inert migration data and confer no authority. See Modes and approvals for review controls.