feat(hooks): surface script reason in synthetic block messages#1045
Open
kamushadenes wants to merge 16 commits intonextlevelbuilder:devfrom
Open
feat(hooks): surface script reason in synthetic block messages#1045kamushadenes wants to merge 16 commits intonextlevelbuilder:devfrom
kamushadenes wants to merge 16 commits intonextlevelbuilder:devfrom
Conversation
WhatsApp LID-format chat IDs contain @ (e.g. 551152861098:5@s.whatsapp.net) which is invalid in Docker container names, causing sandbox creation to fail for any WhatsApp-triggered agent session. Add @ to the sanitizeKey replacer alongside the existing : / . and space characters. Adds a test case with a realistic WhatsApp LID key. Fixes nextlevelbuilder#1029 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The stateless flag was supposed to prevent session history accumulation, but the reset logic was inverted: non-stateless jobs got reset while stateless jobs were skipped. Since the agent loop always persists messages to the session key regardless of the stateless flag, stateless cron jobs accumulated unbounded history across runs. Fix by unconditionally resetting the session before every cron execution. This is consistent with nextlevelbuilder#294 (which added the reset for non-stateless jobs) and ensures stateless jobs actually start fresh each run. Fixes nextlevelbuilder#1029-related session accumulation observed in production. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When an LLM wraps a credentialed CLI in a shell chain like
"which gh && gh pr list", lookupCredentialedBinary only checks the first
binary ("which") and misses "gh". The command falls through to regular
exec, running without credential injection — the CLI reports "not
authenticated" and the agent gives up.
Add detectCredentialedBinaryInChain() which scans all segments of a
shell-operator command for registered credentialed binaries. When found,
returns an actionable error telling the LLM to call the CLI directly
without shell operators, instead of silently falling through.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
…ction When LLMs wrap credentialed CLIs in shell chains (e.g. "which gh && gh pr list"), the credentialed exec gate only checks the first binary and misses the CLI deeper in the chain. The command falls through to regular exec without credential injection. Add a per-CLI `allow_chain_exec` boolean (default: false) that controls behavior when this is detected: - **false (default)**: return an actionable error telling the LLM to call the CLI directly without shell operators (safe, no token leak) - **true**: inject all matching credential env vars into the full command chain and execute via shell (convenient but tokens visible to all commands in the chain) Changes: - Migration 000057: add `allow_chain_exec` column to `secure_cli_binaries` - Store: SecureCLIBinary struct + PG/SQLite CRUD (select, insert, update, scan) - HTTP API: create/update request structs + allowlist - Exec logic: handleCredentialedChain() with two-mode dispatch - Credential context: per-CLI note when chain exec is enabled - Web UI: toggle switch in CLI credential settings form - i18n: English labels + hint text Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
When a pre_tool_use script hook returns DecisionBlock with a non-empty `reason`, the dispatcher now copies it onto FireResult.Reason and the pipeline appends it to the synthetic tool message instead of the bare "Hook blocked: pre_tool_use" line. user_prompt_submit gets the same treatment via a wrapped error. This lets a hook self-document the block to the agent (e.g. retry hints like "use rtk prefix") without expanding the system prompt or relying on out-of-band documentation. Backward-compatible: handlers that do not set a reason — including all non-script handler types (HTTP, command, prompt) — yield FireResult.Reason == "" and the original generic message is used. Tests cover both paths (reason set / not set) and verify Reason stays empty for non-script handlers.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
pre_tool_usescript hook returnsDecisionBlockwith a non-emptyreason, the dispatcher now copies it ontoFireResult.Reason.Hook blocked: pre_tool_use — <reason>(was justHook blocked: pre_tool_use).user_prompt_submitgets the same treatment via a wrapped error.FireResult.Reason == ""and the original generic message is used.Why
Hooks today block silently from the agent's point of view: the agent only sees
Hook blocked: pre_tool_usewith no explanation of why and no actionable hint. Operators end up baking workarounds into system prompts, agent context files, or skill grants. With this change a hook can self-document the block (e.g. a token-saving CLI proxy hook that wants the agent to retry with artkprefix can returnreason: "use 'rtk git status' instead"and the agent will see it inline).Discovered while wiring an
rtk-usage-nudgehook into a fork —ScriptResult.Reasonwas already populated by the script handler (seeinternal/hooks/handlers/script.go) but never made it past the dispatcher.Files
internal/hooks/types.go— addReason stringtoFireResult(doc'd as block-only).internal/hooks/dispatcher.go— copyscriptRes.ReasononDecisionBlockreturn.internal/pipeline/tool_stage.go— surface reason in synthetic tool message.internal/pipeline/context_stage.go— surface reason inuser_prompt_submiterror.internal/hooks/dispatcher_test.go— two new tests:TestDispatcher_BlockReason_PropagatesToFireResult— script handler with reason →FireResult.Reasonmatches.TestDispatcher_Block_NoReason_LeavesReasonEmpty— non-script handler block →Reason == "".Test plan
go vet ./internal/hooks/... ./internal/pipeline/...— clean.go test -count=1 ./internal/hooks/...— 197 pass.go test -count=1 ./internal/pipeline/...— 119 pass.go build ./...— PG build succeeds.go build -tags sqliteonly ./...— desktop/SQLite build succeeds.Hook blocked: pre_tool_use — Use 'rtk git ...' for token-optimized output (60-90% savings)…and retried with the correct prefix.