# Jan Agent safe mode and shell sandbox are different controls

Separate Jan Agent approval prompts from shell confinement, inspect effective project settings and account for memory tools that follow their own policy.

Author: Retrivium team
Updated: 2026-11-03
Canonical URL: https://retrivium.ai/journal/jan-safe-mode-shell-sandbox/
Language: en

Jan Agent has separate controls for reviewing an operation and limiting what a shell process can reach. The distinction matters when a local coding assistant moves from explaining a file to editing or running commands. A confirmation dialog and an execution boundary provide different information about the same proposed action.

## Read the effective launch mode

The [Jan permission guide](https://docs.jan.ai/agent/permissions) distinguishes `--safe` from `--sandbox`. Approval mode asks about relevant tool calls; it does not itself confine a shell. Shell confinement does not automatically enable approval prompts. Existing project or global settings can affect the effective behavior.

For an initial local exercise, state both requirements explicitly rather than inferring one from the other. Inspect the launch mode and project configuration before asking an agent to modify a repository. A familiar product name or visible prompt is not a description of its whole access boundary.

## Inspect the project policy separately

The [project configuration reference](https://docs.jan.ai/agent/project-config) describes the project store and tool configuration. Repository instructions describe desired behavior; runtime policy determines the operations available to the agent. An instruction saying to avoid another directory is not equivalent to denying access to it.

Use a disposable project containing an allowed sample file and an unrelated sample outside the intended boundary. Ask for a harmless inspection and a proposed edit. Observe which operation requests approval and which is prevented by confinement. Do not use personal documents to discover where the boundary lies.

## Understand the scope of a grant

The permission interface can offer a single-call decision or a broader thread-level grant. Read its exact label. Allowing a category of writes is different from approving one file operation; a base-command grant is different from an unrestricted shell grant.

Retain the narrow choice when testing one operation. After denying a proposal, check that no file changed. Also distinguish a policy denial from a model declining to use a tool. Only the first directly demonstrates the configured enforcement path.

## Include durable memory in the inventory

[Jan memory documentation](https://docs.jan.ai/agent/memory) explains that dedicated memory tools have their own approval behavior, including writes that do not prompt in safe mode unless explicitly denied. Consequently, safe mode should not be described as a universal read-only session.

Review which information can become durable project or user memory. Conversation history and memory are different stores. If the exercise requires no persistent notes, express that requirement in the relevant policy and verify the resulting store, rather than relying on the absence of a file-edit dialog.

## Keep recovery distinct from prevention

The [session guide](https://docs.jan.ai/agent/sessions) covers session history and Git-dependent restoration behavior. Recovering an edit after it happened is not the same as preventing the edit. External command effects may also extend beyond a conversation rewind.

For a reviewed coding workflow, combine an understood approval policy, a verified execution boundary and ordinary repository review. Record the installed Jan version and effective settings. This produces a concrete account of what the local agent can do without presenting any single flag as a complete security model.

## Related reading

[llama.cpp server: a local API from a GGUF model](/journal/llama-cpp-server-launch/), [VRAM for LLMs: why model size is only part of the calculation](/journal/vram-and-models/).