Tool Execution in DeepSeek Harness: Guards and Approval (Part 4)

Series: Inside the DeepSeek Harness — Part 4 of 16

Part 3 ended on a specific promise: a tool that’s been restricted away is “absent from the prompt AND refuses execution” — not a prompt trick, but something enforced further down the stack. This post is that “further down.” Every tool call in dsh, from every agent, passes through the same eight-stage pipeline before its result reaches the model — and the interesting part isn’t the stages themselves, it’s the specific, narrow shape each one is allowed to have.

The full chain

tool/call (logged)
  -> tools/pre-execute   (waterfall: allow | deny | ask)
  -> guards               (deny-only, monotonic)
  -> tools/execute        (waterfall: around-dispatch)
    -> tool body
  -> tools/post-execute   (accept | block{feedback} | rewrite content)
  -> finalizeContent
  -> tools/result (emit)
tool/result (logged)

Every one of those waterfall stages is the same Cordis primitive from Part 1 — a listener chain wrapping next(). What makes this pipeline worth its own post isn’t the mechanism; it’s that each stage’s decision type is deliberately narrower than it could be, and each narrowing closes off a specific class of bug.

Guards can only say no

The ToolGuard type is a plain function returning string | undefined. That’s the entire interface — a guard either returns a denial reason, or it returns nothing. There is no allow return value. Not “an allow value that’s discouraged” — it doesn’t exist in the type. This is enforced by TypeScript, not by convention, and the consequence is exactly what it sounds like: no listener, registered at any point in the guard chain, in any order, can turn a denial back into a permission. Guards run global-first, farthest ancestor first, and any one of them can flip the outcome to deny — none of them can flip it back.

Compare that to tools/pre-execute’s decision type, which is a closed three-way union: allow | { deny, reason } | { ask, reason? }. It deliberately excludes input rewriting as an option. A listener that wants to intercept a call can only allow it, block it, or route it to a human — it cannot silently swap the arguments the model asked for. The reason, stated directly in the docs: “arguments are already logged and presented” by the time pre-execute runs — the tool/call event with the model’s actual arguments is already durable. Letting a policy layer rewrite arguments after that point would mean the audit log, the UI, and the thing that actually executes could each observe a different value for what the model “asked for.” One value, agreed on everywhere, is worth more than a convenience feature.

Approval is a separate phase from guards, not a replacement for them

When pre-execute returns ask, that goes through ctx.approval — a single-provider service (real code: packages/interaction/user-approval/src/index.ts:30 for the approval/request waterfall, :192 for ApprovalService) that surfaces a one-shot prompt to a human, over whatever UI happens to be attached: the web dialog, an ACP bridge, an SDK client.

ApprovalOutcome is a closed four-value union: allowed-once | rejected | cancelled | unavailable. What’s notable is that three of the four values are failure modes, and all three fail closed the same way — a missing answerer, a non-owning answerer, a throwing answerer, and a non-conforming response all collapse to the same safe outcome. There’s no ambiguity between “the human said no” and “something went wrong asking the human”; both stop the call.

And critically: allowed-once doesn’t skip the guard chain — it proceeds into it. Approval and guards are independently stacked veto layers, not a single combined check. A human can approve a call that a guard then denies anyway. One more integrity detail worth knowing: approval requests deliberately omit the tool’s arguments. The human correlates via callId to the tool call that was already streamed and logged, instead of receiving a second copy of the arguments in the prompt — specifically so the approval prompt text can never drift out of sync with what’s actually in the durable log.

Token-minted execution: one frozen identity, seen by everyone

Before any policy runs, execute() (packages/core/tools/src/index.ts:1342) delegates to createExecution() (:1364), which does something worth calling out on its own: it takes a lossless snapshot of the call’s arguments, deep-freezes them, and mints an opaque ToolExecutionToken — a Symbol-branded value that identifies this specific execution. Every subsequent stage — guards, tools/execute, the body, tools/post-execute — receives that same frozen identity. No stage can see a different version of “what was called” than any other stage saw.

Cancellation gets a re-check at exactly one seam-crossing point: after tools/pre-execute settles (which may be async — an approval prompt can take real time), the registry re-checks whether the call was cancelled while waiting. If it was cancelled before the body ever started, the failure code is ABORTED_BEFORE_DISPATCH; if the body was already running when cancellation arrived, it’s ABORTED. Two different codes for two genuinely different situations — “never ran” and “was running, then stopped” — because a caller reacting to the failure needs to know which one happened. An already-started body isn’t force-killed; same-process code can’t be terminated safely, so it drains to quiescence instead. (Part 9 covers exactly this mechanism from the loop’s side, including a real bug in how a wake could get dropped during that drain.)

Post-execute: content or value, never both

The last policy stage, tools/post-execute, can do one of three things: accept the result as-is, block it with corrective feedback (the model sees an error instead of the tool’s output), or rewrite the content shown to the model. What it explicitly cannot do is rewrite content and the programmatic value simultaneously — the docs state the rule directly: “content replacement is presentation policy, not confidentiality policy: a listener that must hide the programmatic value blocks or replaces it.” If a listener needs to hide something from the model, it has to actually block the call — there’s no middle path where the model gets a sanitized-looking success while some other consumer of the result still has access to the real value.

Coming up in this series

(All 16 parts are live today — no daily drip.)

Part 16 shipped after this series’ initial 15 posts, once Agent Presets and Code Mode landed — it reads best right after Part 4, which is why its row sits there instead of at the end.

Next: Part 16 is the newest post in this series, threaded in right here because it leans directly on this post’s pipeline — it covers the newest, most consequential design decision in dsh: agent modes as directories, not classes. From there, Part 5 zooms out from “how one call is policed” to “how bash itself gets swapped for sandboxed bash with zero changes to this pipeline” — the three-role seam pattern, end to end.

References

• Source citations pulled directly from the repo as of commit 47f9438 (master, Aug 13, 2026 — same commit cited throughout this series): packages/core/tools/src/index.ts (execute(), guard chain, pre/post-execute waterfalls), packages/interaction/user-approval/src/index.ts (approval/request, ApprovalService), packages/interaction/permission-presets/src/index.ts
• docs/tool-execution-pipeline.md and docs/subsystems/tools.md, deepseek-ai/deepseek-harness
• docs/subsystems/approval.md and docs/subsystems/permission-presets.md
• Part 1 through Part 3 of this series