PATH & Environment Repair

PawOS can add a folder to the real Windows System PATH, or set any named environment variable (JAVA_HOME, ANDROID_HOME, and similar), requesting real administrator elevation when required.

PATH detection

Before writing, PawOS checks whether the target value is already present in the requested scope — an already-correct PATH is reported as such, never re-added.

PATH repair

Writes go to System (Machine) scope by default — the goal is "leave the computer correctly configured," not scoped so narrowly it only helps the current session. PawOS never silently downgrades to a User-scope write on its own.

1. 1

   Attempt un-elevated

   Works immediately if the process already has administrator rights.

2. 2

   Request real elevation

   If Machine-scope access is denied, PawOS requests a genuine Windows UAC prompt.

3. 3

   Confirm by re-reading

   Because exit codes don’t reliably cross the elevation boundary, success is confirmed by re-reading the Machine-scope registry value afterward and comparing it to what was requested — never trusted from the elevated process’s own exit code.

4. 4

   Honest decision point

   If elevation isn’t available (declined, timed out, or a non-interactive session), PawOS reports this plainly and offers the real choice: retry elevated, or settle for a User-scope write instead.

Environment changes

A PATH or environment-variable change made moments earlier is made visible to the very next verification check in the same session — PawOS re-reads Machine+User environment straight from the registry (short-cached, not spawned fresh for every single check) rather than trusting its own long-running process’s stale in-memory environment, which would otherwise wrongly report "still not installed" immediately after a real fix.

Verification, retry, and failure

The same dual-shell (cmd.exe + PowerShell) version check used for software installation verifies a PATH fix. Failure and retry follow the same rules described on the Software Installation page.

Product disclosure

This disclosure is part of the PawOS documentation for PATH & Environment Repair. 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.