Sandbox and File Protection
When LanMate runs commands and writes files, it works inside a restricted environment by default: a system-level sandbox isolates command execution, and file protection limits what can be written. The two layers work independently—no configuration needed for normal use.
System Sandbox
The sandbox uses the operating system’s native isolation mechanism, chosen automatically per platform:
| OS | Backend | Notes |
|---|---|---|
| macOS | Seatbelt (sandbox-exec) |
Built into the system, nothing to install |
| Linux | Landlock first, bubblewrap fallback | Landlock is kernel-native; see “When the sandbox is unavailable” if both fail |
| Windows | Low-integrity process | Built into the system, nothing to install |
| HarmonyOS | System app sandbox | Enforced by the OS; fixed to workspace-only, this setting cannot be changed |
Commands the agent runs (bash, scripts, kernel processes) execute inside the sandbox and cannot write outside their bounds. Built-in office scripts and connector processes are exceptions—see “Coverage”.
File Protection Scope
Settings → Security → File Protection offers two levels:
| Level | Behavior |
|---|---|
| Workspace only (default) | Restricts writable scope via the system sandbox; writing outside the working directory prompts for authorization, then proceeds after approval |
| Unrestricted | Turns file protection off; any file can be written, subject only to the approval level |
Under “workspace only”, the agent may write:
| Permission | Scope |
|---|---|
| Read/write | The current project’s working directory |
| Read/write | System temp directories (macOS /tmp, TMPDIR; Windows %TEMP%; Linux /tmp) |
| Read/write | The current session’s artifact directory (intermediate files like reports and charts) |
| No write | Any path outside the above—first write pops an authorization card |
Out-of-bounds write authorization is session-scoped: approve once and the same path is never asked again within that session; a new session asks anew. Directories you write often (say, a fixed output folder) can be added to always-writable directories (Settings → Security), after which every session can write them directly.
Note: Built-in office scripts (Word/Excel/PPT/PDF/image processing) and connector processes don’t run in the system sandbox, but their reads and writes remain bound by the working-directory and authorization rules, and every execution is recorded in the audit log.
When the Sandbox Is Unavailable
On Linux, if neither Landlock nor bubblewrap works (or user namespaces are disabled), LanMate won’t pretend to be safe: commands run with normal permissions, but three layers of visibility keep you informed—
- A toast appears at the bottom-right on startup
- Settings → Security shows a persistent warning with remediation guidance (e.g., install bubblewrap)
- The first command in each session asks for confirmation once more
Approval interception is unaffected and stays in effect. Restarting the app or fixing the system configuration may restore it.
Other Security Settings
| Setting | Location | Description |
|---|---|---|
| Block network in sandbox | Settings → Security | Disconnects sandboxed processes on Linux (on by default); turn off when installing dependencies requires network |
| LanMate dependencies | Settings → Security | Installs dependencies into the bundled runtime (on by default); off means installs use the system environment, and commands pointing at the bundled environment are intercepted |
| Delete to trash | Settings → Security | Confirmed deletions move files to the system trash instead of removing them permanently—recoverable |
| Restrict channel file paths | Settings → Security | When on, channel sessions (Lansenger etc.) can only send files inside the working directory, preventing data exfiltration |
Execution Policy Rules
Settings → Security → Execution Policy Rules lets you customize allow/deny policies by tool, path, and command:
- Each rule: tool name (exact match) + condition (path prefix / command contains) → decision (allow / deny / ask)
- Rules match top-down; the first hit wins. Unmatched calls fall through to the default decision
Example: tool bash + command contains git push → ask, so routine operations flow freely while pushes keep a human checkpoint.
Security guardrails: Sensitive paths (
~/.ssh,~/.aws,/etc, etc.) and destructive commands (likerm -rf /) are always denied—no rule can override them.
Enterprise Audit
When your organization enables it, approval decisions and high-risk tool calls are reported to the enterprise audit log: command text is masked before upload, and offline reports are re-sent automatically. The full local trail is kept in ~/.lanmate/agent/sessions/<session-id>.jsonl for enterprise forensics.
Relationship with Approval
The sandbox governs “where it can touch”; approval governs “whether it asks you”. The two combine independently—for example, under “workspace only + read-only auto-approve”, reading runs directly, writing prompts, and writing outside the workspace passes sandbox authorization then approval. See Approval and Security.