17 guard and permission rejections in one session, each costing a full retry turn, mostly on command shape rather than policy

[kyle-sexton]

perf/session-latency.md section 7, tier E1, counts 17 blocked or denied tool_result records across the session's 11 transcripts: block-hook-bypass on Bash 15 times, on PowerShell once, and one "Permission for this action was denied". The blocked calls consumed 48.2 s; priced with a forced retry turn at the 3.8 s median model latency, that is 113.5 agent-seconds (section 8B), a lower bound: it omits generation and the replacement tool call.

Two reconciliations. Section 5 reports PreToolUse:Bash block-hook-bypass at 9 against section 7's 15: different populations (hook_system_message attachments versus blocked tool_result records), unstated in the file. This counter is the section 7 population. And the 17 are attributed by message string, not guard name, so the per-guard split is not established: the guardrails evidence file's claim that all 17 were block-hook-bypass contradicts its own worked examples, a ps-unparsable-launcher block and a --force-with-lease block belonging to other guards.

perf/snapshot-baseline.md section 3 corroborates the invocation-form cost: 4 attempts at render-and-lint.ps1 in the main transcript produced exactly 1 real execution: a guard block on the PowerShell form (0.5 s), an Import-Module failure from a -File invocation (2.8 s), a call that printed parameter help and never ran (2.0 s), then the working form at 40.6 s. Three of four were shape errors, not policy violations.

Cheapest fix: have guard rejection messages carry the exact allowed command form, not just the rule that fired, turning a retry loop into one correction. Second: document the working shape for a repo script under pwsh, pwsh -NoProfile -NonInteractive -WorkingDirectory <dir> -Command "<script>; exit $LASTEXITCODE", in the guardrails README next to the launcher rule. The companion issues on the wsl bypass and the /tmp false positives remove separate slices of this count.

Maintainer note: the "PowerShell costs about 5x Bash" line that circulates with this one is tier E4. perf/target-ranking.md rank 7 ran the toolUseID to tool_use.name join: all 9 measured run-guards fires are Bash, zero PowerShell samples in the corpus. No measurement on either side.

Verification: blocked or denied tool_result records per session, baseline 17, from the section 7 population. Also useful: attempts per successful render-and-lint.ps1 execution, currently 4 to 1.

🤖 Generated with Claude Code

https://claude.ai/code/session_01F7GFS5autRMSaea6kSoXzx

[kyle-sexton]

Posted from the 2026-09-29 audit of the Cursor run (499 PRs, 2026-09-27 to 2026-09-29). The owner authorized fixing the findings; merging is not authorized. Fix PR: #5340 (draft).

Reopened. This closed 1 s after #4752 merged: the PR body said it does not close #4261, but a negated keyword auto-closed it. #5340 uses Refs only.

Delivered: the ps-unparsable-launcher message now names a form that passes, and a README note documents the working pwsh shape. Verified in this audit on pwsh 7.6.5 (Linux): pwsh -NoProfile -NonInteractive -WorkingDirectory <dir> -Command '& ./s.ps1; exit $LASTEXITCODE' runs a script that imports a module by relative path and returns its exit code 3, while pwsh -File <abs path> from another directory fails at the relative Import-Module. block-hook-bypass rejections already end with the Write/Edit remedy (#4679).

Not delivered: the verification metric (blocked or denied tool_result records per session, baseline 17 from the perf/session-latency.md section 7 population, and attempts per successful render-and-lint.ps1, baseline 4 to 1) was never re-measured.

Next, for the owner or a data pass: rerun the section 7 transcript join over sessions after this release and report the count per session and the attempts per successful render-and-lint.ps1 run. Keep the caveat from the issue: attribution is by message string, not guard name.

Open design question, left to the owner and not implemented: does the existing Write/Edit remedy meet "carry the exact allowed command form" for block-hook-bypass, or should the message echo the concrete Write call for the blocked target? The second grows the message #4679 shortened.

[kyle-sexton]

Owner decision (2026-09-29): approved consensus

Question: Does the existing Write/Edit remedy in block-hook-bypass meet "carry the exact allowed command form", or should the block message echo the concrete Write call for the blocked target (which grows the message #4679 shortened)? A second item, rerunning the section 7 transcript join after the release, is a measurement, not a decision.

Chosen answer: "Q1: A. Keep the existing Write/Edit remedy; do not echo a concrete Write call. Q2: no decision needed. Run the data pass after the release and report the two numbers, keeping the caveat that attribution is by message string, not guard name. Close #4261 once that measurement is posted, or file a follow-up only if it shows the retry loop persists."

Rationale: The guard's remedy is one fixed instruction (use Write/Edit), which is already the exact allowed form for a file-write bypass, so there is no per-command variation for the message to carry. Echoing a concrete Write call would mean reconstructing the target path and content from an arbitrary shell string that the guard parses only heuristically, and it would undo the #4679 decision to keep stderr to what the agent can act on. Most of the 17 rejections were command-shape errors (3 of 4 render-and-lint.ps1 attempts), which the delivered ps-unparsable-launcher message and README pwsh note already address. The metric was never re-measured, so choosing B now would be speculative.

Next: No code change. After the release, run the section 7 join and report blocked or denied tool_result counts per session (baseline 17) and attempts per successful render-and-lint.ps1 (baseline 4 to 1), noting that attribution is by message string, not guard name. Then close this issue, or file a follow-up for B only if block-hook-bypass rejections are still followed by failed retries. Removing needs-human and agent-ready until the post-release data pass is runnable.

[kyle-sexton]

Owner decision (2026-10-01): approved the recommendation ("go with recommended", the owner's reply to the batch decision page that listed this question and its recommendation).

Question: how and when to take the post-release measurement for this issue (blocked or denied tool_result records per session, baseline 17; attempts per successful render-and-lint.ps1, baseline 4 to 1).

Chosen: option A. An agent runs the post-release transcript join now over local sessions after 2026-09-30T02:17Z (fix PR #5340 merged 2026-09-30T02:16:59Z), posts both numbers here with the caveat that attribution is by message string and not guard name, then closes this issue, or files a follow-up only if block-hook-bypass rejections are still followed by failed retries.

Next: labeled agent-ready; an agent picks up the read-only measurement.

[kyle-sexton]

Post-release measurement, per the Owner decision (2026-10-01), option A.

Population: records after 2026-09-30T02:17Z (fix PR #5340 merged 2026-09-30T02:16:59Z); 129 sessions (2947 transcript files, main plus subagents grouped by sessionId). Scope is this WSL machine's local transcripts under ~/.claude/projects only. The drain agents' own sessions are included.

Metric 1, blocked or denied tool_result records per session (baseline 17): 2466 total across 129 sessions; median 0, mean 19.12, max 1227; 14 sessions had any. Excluding the 3 largest sessions: mean 0.54, max 39. The mean is dominated by a few sessions, so the typical session is far below baseline 17 but the mean alone does not show that.

Split by message string: block-hook-bypass 2039, Disk-hygiene engine gate 293, other guardrails guards 74, permission denial 41, source-control 12, Disk-hygiene belt 7, ps-unparsable-launcher 0.

Metric 2, attempts per successful render-and-lint.ps1 (baseline 4:1): 2 attempts, 2 successes (1:1). Too few samples to call it a trend.

Retry follow-up: of 2041 block-hook-bypass rejections, 1422 were followed by a successful Write/Edit within 2 tool calls (one correction). 86 (4.2%) were followed by another failed or blocked call; 55 kept retrying and 23 immediately repeated the same block. So the retry loop persists in a small tail.

Caveat: attribution is by message string, not guard name. Counts cover this machine only.

Per the decision, the retry tail is evidence for option B, so a follow-up is filed: #5668. It stays with the owner (status: needs-decision); nothing is implemented. Closing this issue as the measurement is posted.