# HARN-CAP-201 — harness capability denied by active sandbox profile

## What it means

A `harness.fs.*`, `harness.env.*`, `harness.random.*`, `harness.net.*`,
`harness.system.*`, or `harness.llm.*` method was rejected by the active
sandbox profile.
Examples:

- `harness.fs.write_text("/etc/passwd", ...)` from a script whose
  `workspace_roots` only include `./build/` — the path is outside the
  permitted set.
- `harness.net.get("https://example.com")` from a script whose egress
  allowlist does not include `example.com`.
- Any `harness.*` capability under `SandboxProfile::OsHardened` when the
  required platform mechanism is unavailable.

The runtime raises the rejection as a typed `tool_rejected` error so
the harness method surface stays narrow — every script-visible
capability tightens the same way at the same boundary, instead of each
ambient builtin growing its own bespoke deny diagnostic.

When the requested operation can be evaluated against the profile
ahead of time (literal path or URL argument, well-known method on a
sub-handle), `harn check` and `harn lint` surface the same diagnostic
at static-check time so callers don't have to actually execute the
script to discover the denial.

## How to fix

- Widen the active sandbox profile via `CapabilityPolicy::workspace_roots`
  or the egress allowlist if the request is legitimate. The relevant
  policy lives in `~/.config/harn/policy.toml` or the per-script
  `CapabilityPolicy` overlay.
- Use `harn graph --json` to inspect which capabilities your script
  actually needs, then narrow the call site to those.
- For tests, switch from `Harness::real()` to `Harness::mock()` /
  `Harness::null()` so the call is recorded without touching the host.
