Software Installation
How PawOS detects, installs, and verifies developer tools — the real implementation.
PawOS can detect a missing developer tool, install it through a real package manager, and verify the install actually worked — a generic capability that works the same way for any winget, npm, pip, or VS Code extension package, not per-application logic.
Missing-tool and software detection
Detection runs a real, package-manager-specific query — winget list --id, npm list -g, pip show, or code --list-extensions — and separately, a version check runs the command in a genuinely fresh shell (not this process’s own environment) to confirm a tool is actually resolvable on PATH right now.
Note
The version check runs in both a fresh cmd.exe and a fresh PowerShell process and requires both to agree — PATH can genuinely differ between the two, and a mismatch is reported honestly ("works in PowerShell but not in Command Prompt") rather than picked arbitrarily.
Installation methods and package managers
| Manager | Install command shape |
|---|---|
| winget | winget install --id <id> --exact --silent --accept-package-agreements --accept-source-agreements (falls back to a plain-name search if the exact id doesn’t resolve) |
| npm | npm install -g <package> |
| pip | pip install <package> |
| VS Code extension | code --install-extension <id> |
Permission flow
Installing, updating, uninstalling, or repairing software is always a confirmed action — PawOS describes exactly what it’s about to run before it runs it, and the request is refused if confirmation is missing.
Installer execution
The install command runs through the same process manager used for long-running processes (an 8-minute timeout, not the 45-second limit used for one-shot commands), since installers for large tools can genuinely take minutes.
Verification
- If you named a specific executable to check, or gave a version-check command, PawOS runs that real check after install.
- If you named a launch command and an expected process name (for a GUI app), PawOS confirms a real new OS process actually starts — not just that the launcher exited without error.
- Otherwise, PawOS falls back to re-running the same package-manager detection query as an honest minimum check.
Retry and failure
If verification fails, PawOS attempts one automatic repair pass (a force-reinstall) and re-verifies — bounded to 3 attempts total, the same generic retry budget every self-healing action in PawOS shares. If verification still fails, the failure is reported honestly, including partial-success cases ("installed, but I still can’t verify it’s working") — never silently marked complete.
Cancellation
If confirmation is denied or the request is interrupted before it’s answered, nothing installs, and Working History reflects the request as stopped or blocked — never as completed.
User-directed vs. Autonomous environment setup
Warning
This distinction matters and is easy to assume incorrectly: a Pro user manually asking PawOS to "install Node.js" is not the same situation as an unattended Autonomous Work run encountering a missing dependency.
| User-directed (chat) | Autonomous Work | |
|---|---|---|
| Who answers the confirmation? | You, in the conversation, in real time | Nobody is present to answer |
| What happens on a missing tool? | PawOS asks; you confirm; it installs | The run reaches a real, structurally-enforced "waiting for permission" state and stops there |
| Can it proceed automatically? | Yes, once you confirm | No — installing software or repairing PATH is never auto-confirmed in an unattended run |
Note
Autonomous Work’s execution mode auto-confirms only file edits (writeFile/applyCodeEdit) — every other destructive action, including software installation and PATH changes, still requires a real confirmation nobody is present to give. See Autonomous Work → Permissions.
Which tier can install software?
Software installation and PATH repair are currently available on every subscription tier, including Paw Go — gated only by the one-time confirmation, not by a subscription check. This is a deliberate finding from a direct implementation audit, not an assumption: unlike writeFile or runCommand (which require Pro’s execution entitlement), install/PATH actions are not currently included in that same gate.
Product disclosure
This page documents the current PawOS behavior for Software Installation. 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 Software 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 Coding Workspace, Task Card, Plan Review card, affected files, status pills, proposed changes, permission summary, command output, diff surfaces, validation results, preview state, and final Work Record.
- For multi-file work, users should see the plan title, scope summary, per-step rationale, affected area, proposed diff when hunk data exists, and Approve, Reject, and Revise controls.
- During execution, users may also see terminal output, running processes, build/test evidence, browser preview state, screenshots, and real file-change summaries.
What PawOS does
- PawOS may inspect project structure, dependencies, import graphs, feature groupings, domain concepts, affected files, and coding memory before proposing work.
- Code edits use structured action requests such as applyCodeEdit and writeFile; applyCodeEdit uses context-anchored hunks against current on-disk content.
- Validation can include syntax checks, import checks, typecheck, lint, build, tests, process health, browser console/network checks, and visual evidence when those tools are available.
Permissions and boundaries
- Plan approval records intent only. It does not bypass applyCodeEdit confirmation, writeFile overwrite checks, command confirmation, git write confirmation, install confirmation, PATH/system confirmation, connector authorization, or deploy authorization.
- Commands are governed by allowlists and execution rules; PawOS is not a raw arbitrary shell.
- A generated diff is only authoritative when it comes from actual hunk data or a real git/file diff. The UI must not invent a diff for a step that has no patch.
Evidence and records
- A real coding completion should show file paths, changed content or diff stats, commands executed, exit codes, relevant output, validation results, and any screenshots or browser evidence used to confirm UI behavior.
- If validation was skipped because a script or config was absent, that skipped state should be disclosed.
- If a plan was rejected, there should be no planned mutation from that rejected plan.
Limitations and user responsibility
- Live Plan Review visual QA, real Pro/Pro Max account execution, and plan-to-execution lifecycle visualization may require an eligible running app/account environment.
- Some non-TypeScript projects remain editable but may not receive the same deep structural analysis as TypeScript/JavaScript projects.
- Whole-file writes can describe intended content, while fine-grained View Changes requires concrete patch hunk data or an actual diff source.
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.