Tool execution problems

• Confirm you’re on Paw Pro or higher — execution requires the advancedRuntimes entitlement; Paw Go is read-only. See Core Concepts → Entitlements.
• Check whether a confirmation is pending — a destructive action waits for your explicit yes before it runs.
• Check the request’s Work Record for the real, specific failure reason rather than assuming.

Product disclosure

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