Installation

PawOS ships as a self-contained Electron application — no separate runtime like Node.js or Python needs to be installed first.

1. 1

   Windows

   Installer packaging is configured for Electron Builder, but public Windows installers are not generally published. When available, first launch signs in, then workspace and OS permissions are requested as needed.

2. 2

   macOS

   A public macOS disk image is not currently verified as published. Do not assume notarization, auto-update, or distribution status until the Download page says so.

3. 3

   Linux

   A public Linux AppImage/package is not currently verified as published. Treat Linux installation instructions as preparatory until a build is explicitly released.

First launch

On first launch you’ll be asked to sign in (Paw Go, the free tier, requires only an account) and grant OS-level permissions PawOS needs for its companion overlay and, if you use voice, microphone access.

What if launch fails?

Check whether the build is from an official source, whether the app has permission to run, and whether your OS blocked an unsigned or unverified package.

Do I need Node.js first?

No for the packaged desktop app. Developer builds of this repository do require the project dependencies and build scripts.

How do updates work?

General public update distribution is not verified in the current docs. Use only the official release/update path when one is published.

Product disclosure

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