fix(pi): stop the edit-write policy blocking atomic, and decide by recoverability

[cameronraysmith]

Root cause

modules/home/ai/pi/default.nix writes edit-write-policy.ts into ~/.pi/agent/extensions/, for pi. atomic loaded it too: getAgentDirs (config.ts:376 at 0.9.13) returns [~/.atomic/agent, ~/.pi/agent] with no filesystem test, and addAutoDiscoveredResources (core/package-manager-auto-resources.ts:188) scans both roots' extension directories additively. A populated ~/.atomic/agent does not suppress the pi root, so every .ts file placed there runs under both agents whether or not either settings file names it.

Under atomic that produced two failures, both reproduced from the session transcript:

• Every edit. atomic's edit schema is { input: string } with additionalProperties: false; there is no path field, and a model that emitted one would be rejected by argument validation before the hook runs. The policy reads a top-level path, so every atomic edit was refused as malformed input without the decision core ever running.
• Writes at a git repository root. jujutsu 0.43.0 appends Hint: lines to the outside-repository diagnostic whenever the probed directory holds a .git directory. The policy anchored that diagnostic at the end of stderr, so the characterization failed and inspection returned indeterminate — which the old policy refused. That is exactly the case that must fall through to the Git branch, so the entire case "git" arm, including the protected-branch check, was unreachable at the root of every ordinary Git repository.

Neither was visible to the oracle: every repository and adapter case is driven by injected fake capabilities, no real jj or git process ever touches the policy, and the adapter rows feed pi's schema. A case at :1651 did construct a trailing Hint: line — and asserted that it should block, which Fail-closed policy in the spec required.

Reclassified arms, and the principle

Decisions are now classified by recoverability, not severity: block only what cannot be undone, announce everything else.

Arm	Was	Now
Protected git branch main/master	block	notify-and-allow
Protected jj bookmark at @	block	notify-and-allow
Conflicted or divergent @	block	notify-and-allow
Diamond topology (wip health, @ parents, join conflicted/parents)	block	notify-and-allow
Git or jj root does not contain the target	block	block (unchanged)
Target in no repository at all	prompt	block
Any indeterminate probe, capability or core exception	block	allow
Malformed tool input	block	block (unchanged)
Target under /nix/store	block	removed

Announcement rather than confirmation is deliberate: pi has no permission system, so a dialog on an autonomous session can have nobody to answer it — the stall pattern removed from the Claude Code git push and nix run gates. notify is fire-and-forget in every mode and cannot deadlock.

Two entries deserve calling out because they are judgement calls rather than transcriptions:

• Target in no repository at all was prompt, and prompt no longer exists. It falls in the "not protected by version control" class alongside containment, so it blocks. On an autonomous session this is not a regression — the old code already blocked it, via interaction unavailable for required mutation confirmation. On an interactive session it is stricter than before. Easy to flip if that reads wrong.
• /nix/store is drwxrwxr-t root nixbld; touch /nix/store/probe returns Permission denied. The check restated a filesystem permission rather than adding containment.

Notification channel, and what it costs

ctx.ui.notify(message, "warning") on pi's ExtensionUIContext. In the TUI it reaches showWarning, which appends to chatContainer — persistent in the scrollback, not a transient toast. Under RPC it emits a notify protocol frame. It is a no-op when the host has no dialog-capable UI (noOpUIContext.notify in core/extensions/runner.ts), so a print-mode run announces nothing.

That hole is the accepted cost of never stalling, and it is reported rather than papered over. ntfy, which the gate-dangerous-commands NOTICE path uses, would close it, but it means a network side effect inside a synchronous tool-call gate and a new runtime dependency — a design decision beyond this change's scope. Flagging it rather than deciding it.

The check asserts delivery: a notify row that announces nothing fails, because a notify decision that discards its signal is a bare allow, which is a different decision from the one the policy declares.

atomic deliberately retains no path-based edit/write gate

After this change atomic has no path-based edit or write policy at all. What remains for atomic is permission-gate's argv classification (registered for both agents) and filesystem permissions. Nothing stops atomic editing on main, or in a repository whose jj join is broken.

This is deliberate, not an oversight. The alternative is teaching the adapter atomic's hashline grammar — and one edit call can carry several [PATH#TAG] sections (grammar.lark:1 file_patch+; assertUniquePreparedPaths rejects only duplicate paths), so a first-header check would authorize a call that also mutates every other named file unchecked. extractFirstHeaderPath in atomic's own edit.ts is a TUI title-line renderer, not an authorization primitive. Doing it correctly means maintaining a second implementation of another project's parser inside a security check, and the evidence did not justify it: the policy's whole recorded history is fourteen refusals and zero true positives, and in the motivating session the model routed around a refusal with a bash heredoc and sed -i within one turn and completed the mutation anyway.

The adapter cannot read atomic hashline edit input case is kept as a forward guard, so that teaching the adapter a second tool grammar has to be a deliberate decision rather than a quiet one.

Verification

nix build --no-link '.#checks.aarch64-darwin.pi-agent-environment-policy'      # 237 cases pass (was 214)
nix build --no-link '.#checks.aarch64-darwin.pi-agent-environment-structural'  # pass

Severity. New and reclassified assertions were replayed against the pre-change policy (ce9c7800); 8 of 9 discriminate:

SEVERE  jj Hint falls through to the Git branch    before=block:Repository inspection failed  after=notify:protected Git branch main
SEVERE  protected branch announced, not refused    before=block|notified=0                   after=notify|notified=1
SEVERE  indeterminate probe permits                before=block                              after=allow
SEVERE  tilde resolves to home, not under cwd      before=block:...inspection failed          after=block:outside a recognized repository
SEVERE  file:// converted before resolution        before=(no export)                        after=/etc/hosts
SEVERE  unicode spaces folded                      before=(no export)                        after=a b.txt
SEVERE  throwing notification still permits        before=block                              after=pass
SEVERE  Git stderr with trailing advice accepted   before=invalid                            after=outside
INERT   atomic hashline edit refused as malformed  before=block                              after=block

The inert row is inert by construction and is reported as such rather than counted.

The structural assertion was checked the same way: replacing the force-exclude with the bare-basename spelling flips everyDeclaredExcluded and noBareBasenameSpelling to false and fails the check. That spelling is a silent no-op in atomic — the - arm compares only the root-relative or absolute path, never the basename — so the assertion pins the one detail most likely to be got wrong.

Not done

The stale evidence anchors in openspec/changes/archive/2026-08-15-configure-pi-agent-environment/verify.md are left alone. They point at a 3406-line version of the check module that no longer exists, but that file records what was verified at the time; re-anchoring it to today's line numbers would make it claim a verification it never performed, and this change moves those lines again.

No ~/.atomic/ or ~/.pi/ state was touched, so atomic stays broken for editing until this lands.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request