Autonomous Work problems

See Autonomous Work → Troubleshooting for the full, dedicated FAQ — most commonly, a run reaching "waiting for permission" is expected behavior, not a bug.

Product disclosure

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