CLI-246 Move prompt submit hook from shell scripts

[kirill-knize-sonarsource]

No description provided.

[sonar-review-alpha]

Summary

What changed:
This PR implements a TypeScript-based handler for the UserPromptSubmit hook callback that scans prompts for secrets before they're sent to Claude. Previously this logic lived in shell scripts; it's now part of the CLI's callback infrastructure.

How it works:

• The hook reads a JSON payload from stdin containing the user's prompt
• Passes the prompt text to the sonar-secrets binary via stdin (new --input mode)
• If secrets are detected, outputs a JSON decision to block the submission
• Gracefully allows submission if unauthenticated, binary not installed, stdin invalid, or scan fails

Why:
Consolidates security scanning logic into the main CLI codebase rather than distributed shell scripts, making it testable, maintainable, and consistent across platforms.

What reviewers should know

Where to start:

1. src/cli/commands/hook/agent-prompt-submit.ts — the main handler; read top-to-bottom for the flow
2. src/lib/process.ts — additions to SpawnOptions and spawnProcess to support stdin piping (lines 31, 59, 75-77)
3. src/cli/commands/analyze/secrets.ts — the new runSecretsBinaryOnText() helper that wraps the binary
4. src/cli/command-tree.ts — how it wires into the claude-prompt-submit hook command

Non-obvious decisions:

• Graceful degradation is intentional — if anything goes wrong (missing binary, no auth, spawn error), the prompt is allowed through rather than blocking. This prevents the hook from becoming a denial-of-service vector.
• The stdinData field in SpawnOptions (and the write in spawnProcess) enables piping prompt text to the binary instead of using a tempfile or args — cleaner and more secure.
• readStdinJson() silently returns early if parsing fails — this allows the hook to run with various payloads without throwing.

Testing:

• Integration tests exercise the real binary with real prompts (including a test secret token)
• Unit tests cover error paths (scan throws, exitCode null) that can't happen with the real binary
• Tests verify both "secrets found" (block) and "no secrets" (allow) paths

---

• Generate Walkthrough
• Generate Diagram

🗣️ Give feedback

[hashicorp-vault-sonar-prod]

CLI-246

[sonar-review-alpha]

Conclusion: Solid implementation. The refactoring of secrets-scan.ts is clean, the graceful-failure approach is consistent with the existing claudePreToolUse handler, and test coverage is thorough. One logic duplication worth addressing before CLI-247 lands.

🗣️ Give feedback

[sonar-review-alpha]

Logic duplication: The auth/binary guard block here (lines 40–47) is structurally identical to the same block in claude-pre-tool-use.ts lines 48–52, and CLI-247 will add a third handler with the same pattern.

If the guard semantics ever change (e.g. a new auth type treated as unauthenticated, or a new binary resolution strategy), all handlers must be updated in sync with no compiler help.

Consider extracting a shared helper before CLI-247 adds a third copy:

async function resolveCallbackDeps(): Promise<{ auth: ResolvedAuth; binaryPath: string } | null>

Each handler would call it once and return early on null, keeping handler-specific logic separated from the shared guard.

• Mark as noise

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
93.1% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[sonar-review-alpha]

LGTM! ✅

The previously flagged logic duplication in the auth/binary guard block remains unresolved — no changes were made to address it in this PR.

🗣️ Give feedback