PawOS won't start
First steps when the app fails to launch.
- Confirm your OS meets the minimum requirements — see Getting Started → System Requirements.
- Restart your machine — Electron apps occasionally fail to acquire a GPU/display lock after a long uptime.
- Reinstall using the latest installer for your platform.
Product disclosure
This page documents the current PawOS behavior for PawOS won't start. 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 PawOS won't start. 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
- Troubleshooting pages should describe symptoms visible in the app: launch failure, sign-in loop, provider missing, command refused, install failure, PATH mismatch, connector disconnected, usage block, payment problem, or preview/build failure.
- A good troubleshooting page should state what the user can check, what PawOS checks automatically, and what evidence to gather before retrying.
- Users should be told when a condition is a limitation rather than something they can fix locally.
What PawOS does
- PawOS reports failures through task cards, Work Records, action results, connector status, usage gates, and validation evidence.
- For commands, installs, PATH repair, builds, and tests, real stdout/stderr or structured validation output should be used when available.
- For connector and billing failures, provider responses or entitlement/balance classifications should guide the message.
Permissions and boundaries
- Troubleshooting should not recommend bypassing confirmation gates, running unsafe shell pipelines, deleting project files, or changing system settings without understanding the impact.
- If a user lacks tier entitlement, connector scope, local permission, or admin elevation, retrying the same request may not help until that condition changes.
- Support instructions should preserve honest limitations and avoid claiming a feature is live when it is not implemented.
Evidence and records
- Useful evidence includes task id, action type, command text when safe, exit code, file path, validation report, connector id, entitlement reason, payment status, and screenshot if UI layout is relevant.
- If a fix is attempted, the Work Record should show the before/after check or explicitly say that verification was not completed.
Limitations and user responsibility
- Some failures require provider dashboards, operating-system settings, administrator prompts, or account/billing support outside PawOS.
- A failure that cannot be reproduced in the current environment should remain documented as not verified rather than closed as fixed.
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.