Filesystem Access

A coding action’s target path is checked against the declared workspace root before any write happens — a path resolving outside that root is refused, not silently redirected. See Core Concepts → Workspaces.

Product disclosure

This disclosure is part of the PawOS documentation for Filesystem Access. It is written to make the product behavior understandable before a user relies on it, pays for it, connects an account, approves a plan, or authorizes a machine-affecting action.

What users see

• Users see confirmation gates, permission prompts, connector authorization screens, blocked-command messages, filesystem boundaries, credential status, and system-action warnings.
• Security documentation should explain which process enforces the rule and what the user should expect on screen.
• When an action is blocked, users should see an explanation rather than a silent no-op.

What PawOS does

• The main process owns execution of security-sensitive actions; the renderer requests actions through typed IPC and preload boundaries.
• Command execution uses allowlisted command structures and avoids raw shell-injection paths for supported command runners.
• Credentials are handled through connector-specific storage and authorization flows rather than being pasted into arbitrary prompts.

Permissions and boundaries

• Plan approval, model confidence, companion personality, or task urgency cannot bypass confirmation gates.
• Actions that affect files, commands, git state, installs, system PATH, deployments, connectors, or external services require the relevant authorization path.
• The docs must not imply that PawOS can safely perform arbitrary destructive work without user or organization approval.

Evidence and records

• Security-sensitive actions should leave evidence of the request, confirmation requirement, result, and failure reason when blocked.
• Credential and connector claims should be limited to configured providers and scopes that actually exist.

Limitations and user responsibility

• No local security design removes the user responsibility to review proposed plans, confirmations, diffs, commands, deployments, and connector side effects.
• External provider security, account policy, and operating-system permission prompts remain outside PawOS control.