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. |
How it works
What you see
- The PawOS desktop app: your companion, the conversation panel, task progress, workspace selection, account and billing screens, and permission questions when an action needs them.
- After signing in you choose a workspace folder, and PawOS asks before it does anything that changes your machine.
What PawOS does
- PawOS turns each request into a task and keeps a record of what happens.
- For files and code, the workspace folder you picked is the project boundary.
- For coding work, PawOS can inspect your project, plan changes, apply them, run commands and tests, and report the results.
Permissions
- Signing in does not give PawOS blanket permission: editing files, running commands, installing tools, connecting accounts or deploying each ask for approval.
- Approving a plan and approving an action are separate — a plan can be approved while later actions still ask first.
- Your plan determines which kinds of work PawOS can carry out.
Records
- Every completed task leaves a Work Record: the actions that ran, their output, files changed, and test results.
Good to know
- Project analysis is deepest for TypeScript and JavaScript projects; other languages are fully editable.
- Local permissions, missing dependencies, organization policy or your plan can stop a request from running — PawOS tells you which.