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
Asking PawOS in chat to install a tool is different from an unattended Autonomous Work run that finds a missing tool.
| 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 confirms file edits automatically; every other change — including software installs and PATH changes — waits for a person to confirm. See Autonomous Work → Permissions.
Which tier can install software?
Desktop source includes software installation and PATH repair actions with confirmation gates. This documentation update did not independently test those actions, their account entitlements, or every package manager.
How it works
What you see
- Your task progress, plan review with affected files and proposed changes, permission questions, command output, diffs, test results, previews and the final Work Record.
- For multi-file work you see the plan, why each step is needed, and Approve, Reject and Revise controls.
- While work runs you can follow terminal output, running processes, build and test results, and preview screenshots.
What PawOS does
- PawOS reads your project structure, dependencies and related files before proposing changes.
- Edits are applied precisely against the current file contents.
- Checks can include syntax, imports, type checking, linting, builds, tests, running-app health and visual checks, depending on your project.
Permissions
- Approving a plan records your intent; each edit, overwrite, command, git change, install, system change, connection or deploy still asks for approval.
- Commands run under clear rules — PawOS is not an unrestricted shell.
- Diffs you see come from the real changes, never an illustration.
Records
- Finished coding work shows the files changed, commands run, their results and output, test results, and screenshots when the change is visual.
- If a check was skipped (for example, the project has no test script), the Work Record says so.
- A rejected plan makes no changes.
Good to know
- Deep project analysis is strongest for TypeScript and JavaScript; every language can be edited.