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 three levels:
| Level | Behavior |
|---|---|
Read-only (read-only) |
Only the system temp directory is writable; the project working directory is not writable by default. Writes inside the working directory require per-write authorization |
| Workspace (workspace, default) | The project working directory + system temp directory + session artifacts directory are writable; writing outside this scope prompts for authorization |
| Unrestricted | Turns file protection off; any file can be written, subject only to the approval level |
Under the read-only level, if LanMate genuinely needs to write a file inside the working directory, bash can carry a sandbox_permissions argument with a justification explaining why, requesting a temporary widening from you—once approved, the widened scope joins the current session’s allowlist.
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 → always-writable directories), 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 | Network is allowed by default; when on, the Linux sandbox goes offline (keep it allowed when installing dependencies needs 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/users/<user-id>/sessions/<session-id>.jsonl for enterprise forensics.
Organizations can also configure a DLP content-security policy: user messages are scanned for sensitive content before being sent to the model. Three levels—audit only (log hits), local reminder (prompt but still send), require approval (blocked without approval, and no session-level grant). Reports contain metadata only, never message bodies.
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.