Repository navigation
Description
Measured on 2026-10-30 through the Claude Code shim against a real Guardian with the shipped policy, on integration at b383e40 and on PR #229 at 9d3efa3, Bun 1.3.14. Both trees give the same result, so PR #229 does not cover this. These ran through a stub Guardian and the real host-adapter.
| Input | Result |
|---|---|
| Decision string the host does not know, default posture | The step runs at both gates. render throws, the failure is decision_unrenderable, and proceed applies |
id: null with both error and a result carrying a decision |
Honored as a decision for a different request_id. guardian-client.ts:238 returns before either correlation check |
Result with no request_id |
Honored, though the response schema requires it |
tool_name typo in a hookmap |
Loads clean, then every step is allow under proceed |
| Two outputs mapped to one path in a hookmap | Loads clean and drops a modify |
govern-step.ts:19, the host adapter README, and result-output.ts:97 say a decision that arrives is honored. An unknown decision arrives and gets replaced with allow. The first three rows need a non-conformant or newer Guardian, and the last two need a hookmap edit, so none is reachable from the shipped pair.
Expected: an unrecognized decision denies regardless of posture, a response that fails correlation is a delivery failure, and loadHookmap refuses a map that cannot govern. Issue #182 covers a deny with no reasoning, which is related but separate. PR #229 reclassifies -32004 as a refusal and does not touch these.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsAccepted
Activity
[-][Bug] The host adapter honors responses it should reject, and some of them become allow[/-][+][Bug] `loadHookmap` accepts hookmaps that cannot govern[/+]rocklambros commentedon Oct 31, 2026
Correction: I missed PR #249 when I filed this. Tested at 3f4debc through the real client, it rejects all three response rows in the table: the unknown decision, the
id: nullresponse, and the missingrequest_id. Those stay with PR #249.This issue now covers the two hookmap rows, which PR #249 does not touch: a
tool_nametypo and two outputs mapped to one path both still load clean.