Skip to content
PawOS Docs

AI provider problems

When PawOS doesn’t respond, or tools don’t work.

Warning

Tool-calling (the mechanism behind every real action PawOS takes — file edits, commands, installs) requires an action-capable PawOS reasoning configuration. If you switch to a provider mode that only supports conversation, PawOS can still answer questions, but action requests will not be reachable the same way.

If actions are not running at all, check Settings → AI Model and confirm the active model/provider is action-capable for your tier.

Product disclosure

Implemented

This page documents the current PawOS behavior for AI provider problems. 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 AI provider 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.

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.

Related