Quickstart

1. 1

   Sign in

   Paw Go (free) requires only an account — no payment method.

2. 2

   Say or type something low-risk

   "Open my downloads folder" is a good first request — it exercises the full plan → confirm → execute loop without touching anything sensitive.

3. 3

   Watch it narrate

   PawOS describes what it’s about to do before doing it, and asks for confirmation before anything destructive.

4. 4

   Check Working History

   Every completed request leaves a real Work Record — open it from the sidebar to see exactly what ran.

Product disclosure

This disclosure is part of the PawOS documentation for Quickstart. 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.