First Workspace
Pointing PawOS at a real project folder.
A workspace is a project folder PawOS has been given a scoped, confirmed boundary to work inside — see Core Concepts → Workspaces for the full model.
- 1
Ask PawOS to open a project
e.g. "open my project at C:\dev\my-app" or drag a folder onto the companion.
- 2
Confirm the workspace boundary
PawOS only reads/writes inside the folder you named — it will ask before it needs to act outside it.
- 3
Ask a read-only question first
e.g. "what does this project do?" — available on every tier, since it doesn’t require the execution entitlement.
| Workspace topic | Behavior |
|---|---|
| Root folder | The selected folder is the normal boundary for coding and file actions. |
| Existing repository | Git status, diff, log, branch, and commit actions use the repository when one is present. |
| Unsupported layout | PawOS can still read files, but framework/build/test detection may be incomplete or skipped. |
| Changing workspace | A later task can point at a different folder; previous Work Records keep their own evidence. |
| Outside access | Writes and commands outside the declared boundary require explicit checks and are refused when unsafe. |
| Symlinks and traversal | Path normalization and workspace-security checks are applied before writes or commands execute. |
Product disclosure
This page documents the current PawOS behavior for First Workspace. It is intended to disclose what users can see and use, what permissions are required, what evidence is recorded, and what limitations remain.
This disclosure is part of the PawOS documentation for First Workspace. 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
- The desktop application, companion surface, task card, workspace picker, account and billing surfaces, confirmation prompts, and Working History.
- Documentation pages explain the product path, but the operational product is the local Electron app running on the user machine.
- A new user normally sees sign-in, workspace selection, model/provider configuration where needed, and permission prompts only when a requested action needs them.
What PawOS does
- PawOS turns a user request into a task, records the task timeline, and routes read-only analysis separately from execution-class actions.
- When the task is about files or code, PawOS uses the selected workspace folder as the normal project boundary.
- For coding tasks, PawOS can inspect project structure, plan work, request approval, apply patches, run commands, validate results, and report evidence.
Permissions and boundaries
- Starting PawOS, signing in, or reading documentation does not grant blanket permission to edit files, run commands, install tools, change PATH, use connectors, or deploy software.
- Plan approval and action authorization are separate events. A plan can be accepted while later destructive actions still require their own confirmation.
- Subscription entitlements determine whether a request can move from read-only analysis into execution.
Evidence and records
- A completed task should leave a Work Record containing the real actions that ran, outputs, files changed, validation results, failures, and skipped steps.
- If an action was not run or could not be verified, the docs and Work Record should describe that limitation instead of implying success.
Limitations and user responsibility
- Public installer and update availability may vary by platform and release channel; use the Download page as the source of current distribution status.
- Some advanced project-understanding features are strongest for TypeScript and JavaScript projects and may be thinner for other languages.
- Local machine permissions, missing dependencies, organization policy, connector scopes, or subscription tier can prevent an otherwise valid request from executing.
Warning
PawOS can assist with planning, coding, automation, connectors, billing flows, and system operations, but the user remains responsible for reviewing plans, confirmations, diffs, command effects, connector side effects, billing actions, and final outputs before relying on them.