Introduction

PawOS is a native Electron desktop application — an AI companion that runs on your machine and can take real, confirmed action on your files, terminal, browser, and connected services.

It is not a browser-based chatbot and there is no PawOS web app for everyday use. The desktop app is the product. This site exists to explain, document, and distribute it.

How it works, at a glance

A conversational runtime (main process: ConversationRuntime + ExecutionSupervisor) turns what you ask for into typed action requests, dispatches them through a plugin-based execution engine (DesktopExecutionEngine), and records what actually happened as structured evidence — not a summary the model wrote after the fact.

• Reasoning is model-driven; execution is deterministic code, not the model directly touching your machine.
• Anything destructive (writing files, running installers, modifying PATH, deploying) requires an explicit confirmation before it runs.
• Every completed request produces a Work Record — real evidence of what ran, what changed, and what was verified.

How these docs are organized

Your first 10 minutes with PawOS

1. 1

   Start with the desktop app

   PawOS is desktop-first. The website documents the product, but everyday work happens in the Electron app beside your files, browser, terminal, and companion overlay.

2. 2

   Think in tasks

   Ask for outcomes: "explain this repo", "add dark mode", "run the tests", or "prepare this ticket." PawOS groups each request into a task with its own evidence.

3. 3

   Select a workspace

   For coding and file work, point PawOS at an explicit folder. That folder becomes the normal filesystem and command boundary for the task.

4. 4

   Use read-only questions first

   Ask what the project does, what framework it uses, or which files a feature might touch. Project understanding is available before execution.

5. 5

   Review plans before mutation

   For non-trivial coding edits, PawOS can show a visual Plan Review card before changes are applied.

6. 6

   Approve deliberately

   Plan approval is not the same as authorizing every destructive action. PawOS still asks before real edits, commands, installs, PATH changes, git writes, or deploys.

7. 7

   Check the Work Record

   After a task, open the evidence trail: what ran, what changed, what passed, what failed, and what was not verified.

Product disclosure

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