mosaicstack/stack
25
0
Fork 1
Code Issues 344 Pull Requests 13 Actions Packages Projects Releases 15 Wiki Activity

wrapper-guard.sh: BLOCK verdict text goes only to stdout - Claude Code PreToolUse blocks are silent #1493

New Issue
Open
opened 2026-09-04 17:36:00 +00:00 by orch-01 · 0 comments
orch-01 commented 2026-09-04 17:36:00 +00:00
Member
Copy Link
Copy Source

Defect

wrapper-guard.sh prints every BLOCK verdict to stdout (all cat <<EOF block-message sites) and exits 2. Harness PreToolUse contracts differ in which channel they surface on exit 2:

  • Claude Code feeds only stderr back to the model on exit 2. The agent sees hook error: ... No stderr output and the entire block rationale is lost: the block is effectively silent.
  • The pi wrapper-guard listener reads res.stdout || res.stderr, so pi users see the message.

The guard's own contract states every block emits a message. On Claude Code, none is delivered.

Repro (direct, no harness)

Input {"tool_name":"Bash","tool_input":{"command":"curl -s \"$U/api/v1/x/$V\" -d x"}} piped to the guard:

  • rc=2
  • stdout: 896 bytes (full BLOCK verdict)
  • stderr: 0 bytes

The hermetic suite captures 2>&1 at every assertion site, so it cannot detect the channel and passes 310/310 while the Claude path is silent.

Related observation (by design, documented here because it compounds this defect): the guard judges the whole submitted command text, so a command whose literal text embeds a guarded payload shape (e.g. a test fixture string) is itself blocked. That is correct per the header, but combined with this defect the operator receives an unexplained block.

Fix shape

  1. Emit the block message on stderr (or emit the Claude verdict JSON {"decision":"block","reason":...} on stdout with human-readable text on stderr), keeping pi compatibility (read stderr first, or dual-emit).
  2. Add suite arms that assert the verdict text lands on the channel each harness reads: a stderr assertion on the exit-2 path and a stdout assertion for pi consumers. No 2>&1 captures.

Environment: bash 5.x; packages/mosaic/framework/tools/git/wrapper-guard.sh (current next) as deployed to framework tool trees; Claude Code and pi harnesses.

## Defect `wrapper-guard.sh` prints every BLOCK verdict to **stdout** (all `cat <<EOF` block-message sites) and exits 2. Harness PreToolUse contracts differ in which channel they surface on exit 2: - Claude Code feeds only **stderr** back to the model on exit 2. The agent sees `hook error: ... No stderr output` and the entire block rationale is lost: the block is effectively silent. - The pi wrapper-guard listener reads `res.stdout || res.stderr`, so pi users see the message. The guard's own contract states every block emits a message. On Claude Code, none is delivered. ## Repro (direct, no harness) Input `{"tool_name":"Bash","tool_input":{"command":"curl -s \"$U/api/v1/x/$V\" -d x"}}` piped to the guard: - rc=2 - stdout: 896 bytes (full BLOCK verdict) - stderr: 0 bytes The hermetic suite captures `2>&1` at every assertion site, so it cannot detect the channel and passes 310/310 while the Claude path is silent. Related observation (by design, documented here because it compounds this defect): the guard judges the whole submitted command text, so a command whose literal text embeds a guarded payload shape (e.g. a test fixture string) is itself blocked. That is correct per the header, but combined with this defect the operator receives an unexplained block. ## Fix shape 1. Emit the block message on **stderr** (or emit the Claude verdict JSON `{"decision":"block","reason":...}` on stdout with human-readable text on stderr), keeping pi compatibility (read stderr first, or dual-emit). 2. Add suite arms that assert the verdict text lands on the channel each harness reads: a stderr assertion on the exit-2 path and a stdout assertion for pi consumers. No `2>&1` captures. Environment: bash 5.x; `packages/mosaic/framework/tools/git/wrapper-guard.sh` (current `next`) as deployed to framework tool trees; Claude Code and pi harnesses.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Defect in framework tooling or delivered code
 fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
code-be-01 (Mosaic fleet seat code-be-01) code-be-02 (Mosaic fleet seat code-be-02) code-dogfood-01 (Mosaic fleet seat code-dogfood-01) code-infra-01 (Mosaic fleet seat code-infra-01) darkwing (Mosaic fleet seat darkwing) dewey (Mosaic fleet seat dewey) fargo filbert (Mosaic fleet seat filbert) fred gate-merge-01 (Mosaic fleet seat gate-merge-01) happy jason.woltje (Jason Woltje) marcie merge-gate ops-01 (Mosaic fleet seat ops-01) ops-02 (Mosaic fleet seat ops-02) ops-03 (Mosaic fleet seat ops-03) ops-ci-01 (Mosaic fleet seat ops-ci-01) ops-deploy-01 (Mosaic fleet seat ops-deploy-01) orch-01 (Mosaic fleet seat orch-01) pepper resume rev-code-01 rev-code-02 rev-security-01 rev-security-02 rev-security-03 (Mosaic fleet seat rev-security-03) rocko (Mosaic fleet seat rocko) sanity scooby (Scooby) scrappy shaggy tiny topher (Mosaic fleet seat topher) velma veronica (Mosaic fleet seat veronica) vision woodpecker
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1493