chrome-sensitive-ops

chrome-sensitive-ops

Purpose

A foundation primitive for the sensitive lane. The non-sensitive lanes (personal, wovol, school) can use the more permissive arc-browser-ops. This skill exists because sensitive contexts need a stricter set of defaults — and giving them their own primitive makes those defaults harder to bypass by accident.

Hard prerequisites

• A separate Chrome user-data-dir for the sensitive profile, initialized via scripts/profile-init.sh sensitive
• The user has manually logged into each sensitive service in that profile, once, with full attention
• config/domain-allowlists/sensitive.txt is populated with the exact hosts the user intends to allow in this profile

Profile check

python3 "$WOVOL_LAB_ROOT/.claude/skills/_foundation/profile-manager/scripts/profile.py" verify sensitive || exit 2

Hard rules

These are enforced at the skill level AND by the standard hooks ( pre-submit-confirm, sensitive-mode-gate, profile-mismatch-detector):

1. No browser_navigate. The user must have the tab open already. browser_navigate in the MCP wrapper does not inherit the user's cookies on first call, which can land the session at a login page — a wrong place to be in sensitive context.
2. No browser_click on action elements. Submit, send, transfer, pay, confirm, approve — none of these. Read-only inspection only.
3. No browser_evaluate or browser_run_code. Both are disabled in the sensitive lane regardless of allowlist.
4. No downloads. Sensitive PDFs (bank statements, medical records, tax filings) get downloaded by the user manually — the skill never triggers a download dialog.
5. No orchestrator invocation. The skill refuses if it detects that it is being called from a non-interactive context (e.g. a launchd job).
6. Domain allowlist enforcement. Every URL touched by the skill is checked against config/domain-allowlists/sensitive.txt via lib/safety-checks/domain_allowlist.py. A host not on the list aborts.

Operations the skill is for

• Read-only inspection: account balance, statement totals, application status, appointment listing
• Snapshot for the audit log: take a structured note of what was shown on the screen, with PII redacted via the standard pii-secret-scanner pass

Operations the skill refuses

• Anything irreversible (submit, send, transfer, withdraw, schedule, cancel)
• File downloads (manual click only)
• Any action when the domain isn't on the allowlist
• Any action when WOVOL_PROFILE is not sensitive

Standard playbook

0. Save current frontmost app: bash lib/macos/return-focus.sh save
1. Verify CDP up on the sensitive port: curl http://localhost:9225/json/version
2. Find the tab via browser_tabs list
3. Switch to it (browser_tabs select)
4. browser_snapshot
5. Extract only the data you need (read-only)
6. Audit log entry with redacted summary
7. Output to user; never auto-act
8. Restore caller focus: bash lib/macos/return-focus.sh restore

Step 0 and 8 are paired — even on failure paths (CDP down, tab not found, allowlist refusal) always invoke return-focus.sh restore so the user's working app comes back to the foreground. Opt-out: WOVOL_LAB_NO_RETURN_FOCUS=1.

Failure modes

Symptom	Cause	Action
CDP not up on 9225	Chrome not running with sensitive profile	Ask user to run scripts/browser-launcher.sh sensitive
Tab not found	User hasn't opened the page	Refuse — say "open the page in the sensitive profile first"
Domain not in allowlist	Misconfig or unintended redirect	Abort immediately; surface the host so user can decide whether to add
WOVOL_PROFILE ≠ sensitive	Wrong profile	Hook stops execution; user switches profile

What this skill does NOT do

• Inherit any state across sessions automatically (each invocation is bounded)
• Cross profiles (a sensitive-profile skill cannot read from the personal profile and vice versa)
• Cache snapshot content beyond the current invocation
• Surface PII through the digest layer (digest skills are not allowed to call this primitive)