Summary

Hardens the chat lifecycle hooks stack based on a deep security review of #27401, #27428, #27429, and #27430 (merged-stack review at a31e5f3b, re-verified against 6aef61a0). Four of the findings below were validated with executable PoCs during the review; the rest were confirmed by static trace.

The stack has since merged to main (byte-identical in its own paths), so this PR is rebased onto main. Every fix was re-validated against the merged code: none were incorporated during the merge, and the only new chat endpoint since the review (getChatCost, read-only) does not feed hook dispatch.

Problem / Fix

1. pre_tool_use policy bypass via poisoned tool input (validated PoC). toolschema.ValidateUnambiguous treated any JSON tokenizer error as acceptance. Prefixing tool input with "_x":1e999 (a float64 overflow that json.Unmarshal skips inside ignored fields) aborted the walk before a case-variant key such as COMMAND was inspected, so the hook consumer approved one command while coderd executed another. The walk now uses json.Number and fails closed on any tokenizer error, with regression tests.

2. Ambiguity guard did not cover computer-use. The guard only checked tools in BuiltinToolNames; computer-use is a provider tool with a local runner and an empty advertised schema, so case-variant keys (including inside batched OpenAI actions) were never validated while both providers' decoders fold keys case-insensitively. The guard now covers locally-run provider tools, with an explicit property set for both computer-use decoders.

3. Hook responses were unauthenticated. Requests carry a body-bound JWT, but any traffic injected on the return path (the documented plain-HTTP loopback hop, or any hop behind a TLS terminator) could forge allow/deny/input_override decisions without knowing the secret. Every 2xx response must now carry a Coder-Hook-Signature JWT echoing the request claims (jti, type, sub, aud) with body_sha256 recomputed over the exact response bytes. NewHTTPHandler signs automatically; new SignResponses wraps arbitrary handlers; the dispatcher rejects unsigned/mismatched responses as protocol errors (fail closed).

4. Admission events hid instruction channels (validated PoCs). user_prompt_submit carried only the prompt, so operator policy could be bypassed by putting instructions in the per-chat system_prompt or unsafe_dynamic_tools[].description at create, or persistently via PUT /chats/config/user-prompt, none of which produced any hook event. The event now carries system_prompt, custom_prompt, and dynamic_tools, so a policy sees every channel admitted with the turn.

5. Unbounded request bodies with 12x heap amplification (validated PoC). postChatMessages and patchChatMessage had no http.MaxBytesReader (unlike postChats), and each oversized message multiplied into ~12x heap allocations per hook dispatch plus 2x egress to the operator endpoint. Both handlers now cap bodies at 2*maxSystemPromptLenBytes (256 KiB), matching postChats.

6. Uncapped hook response fields. Only model_context was capped; user_message, permission.reason, and input_override could ride the 1 MiB envelope into the LLM prompt, DB, and UI. Now capped at 16 KiB / 4 KiB / 256 KiB respectively.

7. Tool-name alias evasion. Events reported the deprecated alias (close_agent) while execution resolved the canonical tool (interrupt_agent), evading name-keyed policies. Events now report the canonical name. Deprecated alias names are also reserved from unsafe_dynamic_tools: a dynamic tool named after one previously executed client-side while events reported the canonical builtin and the input guard validated it against the builtin schema, rejecting schema-correct calls.

8. message_agent failed open on dispatch failure. Unlike spawn_agent, a hook dispatch failure became a tool error string the model could ignore. It now fails the turn closed, and dispatch errors are redacted (event, class, dispatch ID) before persisting into client-visible tool results; previously the raw error embedded the operator's hook URL/internal host.

9. Hidden-row edit overwrote hook-injected policy context. The message edit path accepted visibility=model user-role rows (exactly what hooks inject as model_context) as edit targets, letting a chat owner rewrite policy context the model trusts. Hidden rows are now rejected as not-found, keeping their IDs unprobeable.

Docs (chat-lifecycle-hooks.md, chatd ARCHITECTURE.md) document response signing, the new admission fields, response caps, and input-hash deduplication for tool events (a replayed tool_use_id with different input previously inherited a cached allow). A UAT pass closed six more contract gaps in chat-lifecycle-hooks.md: guard coverage for locally-run provider tools, fail-closed over-cap responses, message_agent fail-closed plus redacted dispatch errors, the full response-token claim contract for non-Go consumers, unprobeable hook-injected rows, and custom-prompt snapshot behavior across break-glass windows.

Deliberately not addressed here (need a design call)

• Interrupted turns skip post_tool_use/stop dispatch for already-persisted results (consumer state divergence).
• The deployment-global 256-slot dispatch semaphore with fail-closed callers allows cross-user chat DoS under hook-load pressure.

Validation

• New tests: parser-differential fail-closed cases, computer-use/nested-action guard coverage, response signing (unsigned/tampered/cross-dispatch/cross-chat/cross-event), response field caps, admission channel fields, hidden-row edit rejection.
• go build ./...; full test suites for codersdk/x/agenthooks, coderd/x/agenthooks/dispatch, coderd/x/chatd (+ chatstate, chathooks, toolschema), and coderd -run Chat all pass against a real Postgres.
• golangci-lint clean on touched packages; typesGenerated.ts regenerated.
• Re-run after the rebase onto main: build, the same test suites, lint, and a typesGenerated.ts regeneration check all pass.

🤖 Generated with Mux