[Bug] PreToolUse is not dispatched for tool calls carrying sandbox_permissions

[Hello-wenlj]

Type: bug / hooks
Severity: high — the host's own sanctioned escalation path bypasses every PreToolUse gate
Version: dsh 0.2.1-rc.2 (DSH Desktop), Windows 10/11 (win32)
Component: tool dispatch / sandbox escalation (not the sandbox policy layer)
Date observed: 2026-10-19 → 2026-10-21 (the write case on 10-21; the shell cases across
those three days), all four write calls and both context calls in a single session

---

Summary

When a tool call carries sandbox_permissions (e.g. "danger-full-access") plus
justification, DSH dispatches PostToolUse but not PreToolUse for that call.
The call itself succeeds. Every hook registered on PreToolUse — policy checks,
budget guards, structure gates — is silently skipped.

This is not an attacker filling in a privileged field. It is the escalation retry that
the host itself prompts for: first attempt has no parameters → PreToolUse fires normally
→ sandbox denies → host appends
[sandbox: escalation available — retry this exact operation once with sandbox_permissions …]
→ agent retries with the parameters → that retry gets no PreToolUse.

Environment

Host	DSH Desktop, harness dsh 0.2.1-rc.2
OS	Windows (win32)
Default sandbox mode	workspace-write
Workspace root	<workspace>
Target paths (all outside the workspace)	<skills root>, %APPDATA%\dsh-desktop\harness\skills\...
Hooks config	%APPDATA%\dsh-desktop\harness\hooks\hooks.json, 2 separate command entries on PreToolUse

Steps to reproduce

Minimal, 3 steps:

1. Ask the agent to write a file outside the workspace root (default workspace-write).
   The first attempt is denied with file access denied under workspace-write mode,
   followed by the host's own [sandbox: escalation available — ...] hint.
2. Let the agent retry per that hint, with
   "sandbox_permissions": "danger-full-access" + "justification": "...".
3. Inspect the hook ledger: that tool_use_id has PostToolUse only, no PreToolUse.
   The file is written.

Evidence

Ledger: <workspace>\.dsh-hooks-state\hook-observations.jsonl plus the two aggregate ledgers
under %APPDATA%\dsh-desktop\harness\hooks — 707 rows for 2026-10-21, 6734 rows total,
backup snapshots excluded. Counted from disk by script, not sampled by hand.

The four write calls in that session

tool_use_id	time (UTC)	in_bytes	escalated?	PreToolUse	PostToolUse	result
call_00_…emkc5031	14:32:29	116	no	yes	yes	denied (file access denied under workspace-write mode)
call_00_…A5612	14:33:02	364	yes	no	yes	written
call_00_…v5130	14:38:55	376	yes	no	yes	written
call_00_…o7966	15:23:55	412	yes	no	yes	written

Calls 1 and 2 form a clean A/B pair: identical content and identical target path
({"content": "probe\n", "file_path": "...\.probe.md"}), 116 bytes vs. 364 bytes —
the only difference is the three escalation fields, and they flip "denied" into "written"
while also dropping PreToolUse. Calls 3 and 4 carry different content and, in the case of
call 4, a different target (DSH's own built-in skills root); they are additional instances
of the same behaviour, not the controlled comparison.

How "escalated?" was determined (the ledger does not store full tool_input)

The ledger keeps a 240-character in_prev preview plus the true in_bytes length.
For the first call the preview holds the complete payload — 116 bytes, no escalation fields:

{"content": "probe\n", "file_path": "C:\\Users\\<user>\\...\\.probe.md"}

For the second call the preview shows the field verbatim:

{"content": "probe\n", "file_path": "...", "sandbox_permissions": "danger-full-access", "justification": "..."}

For calls 3 and 4 the JSON key order pushes sandbox_permissions past the 240-char window,
but the payload still carries justification, and the byte counts (376 / 412 vs. the 116-byte
baseline) leave no room for anything else. Decisive independent check: all three escalated
calls wrote successfully to paths outside the workspace, while the non-escalated call to
the same directory was denied. Writing outside workspace-write is impossible without
the escalation fields, so their presence is established behaviourally, not just textually.

The dispatch channel itself is healthy

On the same day, 28 distinct tool_use_ids do have PreToolUse — read, grep, glob,
web_fetch, web_search, ask_user, ask_user_question, validate_dsh_ui,
anysearch_capabilities, and one non-escalated write. So this is not "hooks are broken";
it is specific to the escalation path.

Second tool family: shell

time (UTC)	tool	in_bytes	PreToolUse	PostToolUse	note
2026-10-19 15:29:30	pwsh	421	yes	yes	read-only command
2026-10-20 02:51:20	pwsh	98	yes	yes	read-only command
2026-10-21 23:08:08	pwsh	1051	no	yes	deleted 3 files outside the workspace, returned real output

The shell case matters twice: it shows the defect is not write-specific, and it shows
pwsh is normally inside the PreToolUse dispatch surface (2 of 3 calls got Pre).

Sample hygiene note

One more PostToolUse-only call exists that day (evolve_write, in_bytes=93,
{"kind":"memory","action":"delete","id":"..."}). It carries no escalation fields and
does not touch the filesystem, so it is excluded from this report. Its missing PreToolUse
is a separate question (possibly "not in the dispatch surface at all") and is not counted here.

Expected behaviour

sandbox_permissions decides where a call may write; it must not decide whether gates
run. The two are orthogonal. Specifically:

• A call carrying sandbox_permissions should dispatch PreToolUse like any other call.
• If a gate denies, escalation must not override it — otherwise escalation becomes a
  gate-free channel for exactly the calls that most need checking.
• If gates ever are to be skipped, that should require an explicit user decision,
  not a field the agent writes into tool_input itself.

For comparison, Claude Code treats a new tool_use_id as a new call and dispatches Pre/Post
as a pair. Here 4 distinct tool_use_ids were produced and only 1 received PreToolUse.

Root-cause pointer

Byte scan of app.asar (352 MiB):

pattern	hits	overlap with hook dispatch
sandbox_permissions	68	0
PreToolUse	22 (all inside two bridge packages' event-name tables)	—
PreToolUse context containing a skip/bypass predicate	0	—

There is no explicit branch of the form "if sandbox params present, skip hooks". The
effect comes from the dispatch path itself: the escalation retry is apparently not routed
as a tool call that needs the hook pipeline. So the fix belongs in the tool dispatch
layer, not in the sandbox policy module.

Impact

Anything registered on PreToolUse is bypassed for escalated calls: policy/permission
checks, budget guards, memory guards, structure gates, trace/proof guards. In my own
project this reduced a "pre-write gate" to a "post-write detector" for precisely the
scenario it exists for — writes outside the workspace. That day, 4 such writes were made;
3 were escalated, and all 3 escalated ones bypassed the gate while the single
non-escalated one was checked (and then denied by the sandbox).

Narrow workaround (for users, until fixed)

Adding the target root (e.g. a skills directory outside the workspace) to the sandbox's
writable roots makes the first attempt succeed, so the escalation branch is never
entered and PreToolUse dispatch is preserved. This widens exactly one directory.

Not recommended: switching the default mode to danger-full-access to "make hooks
visible again" — that trades the whole sandbox boundary for gate visibility.

How to verify a fix

Any hook on PreToolUse can self-check this on a stock DSH install. Register a hook that
appends the raw stdin payload to a file, then make two calls that differ only in the
sandbox_permissions field:

#	Call	PreToolUse expected
1	write to a path outside the workspace, no sandbox_permissions	✅ arrives (and the call is then rejected by the sandbox)
2	the same write, retried with sandbox_permissions: "workspace-write" + justification	✅ arrives — this is the bug

The fix is confirmed when row 2 also produces a PreToolUse record whose
tool_input.sandbox_permissions is visible in the hook payload itself. Two notes on
reading the result:

• Do not judge presence from a truncated preview of the payload. In our ledger the
  tool_input preview is capped at 240 characters, which cut off exactly the field under
  test on 3 of 4 calls — enough to reverse the conclusion if read carelessly.
• Pair records by tool_use_id, not by timestamp window: a hook process can write its
  record a second or two after the event, and unrelated calls interleave.

The pairing rule that produced the table above is a dozen lines, so it is worth stating
explicitly rather than shipping a tool: group records by tool_use_id, then for each id
require both a PreToolUse and a PostToolUse record; any id with the latter but not
the former is a candidate gap. To confirm a specific gap, dump every record whose
timestamp falls in that one second — that is how the "no PreToolUse in that second" claim
in §Evidence was re-verified, since it rules out the possibility that a neighbouring call's
record was misattributed to this id.

One caveat on the pairing rule: if your hook runner writes records without a
tool_use_id, its records cannot be attributed to any call, and a naive "Post without Pre"
sweep will report them as gaps. In our ledgers 2495 of 2559 PreToolUse rows carry no
tool_use_id — 2231 of those from one legacy runner — so the false-positive rate is not
theoretical: filter by tool_use_id presence before computing the gap, and treat
unattributable records as unknown rather than as evidence.

---

[Hello-wenlj]

Addendum — same-session A/B/A control

Extra evidence collected after the report above. It changes no conclusion; it exists to rule
out the strongest alternative explanation for the original observation — that the missing
PreToolUse was an environment difference between observation periods rather than a property
of the call.

Three calls inside one session, using one tool (write) against one target file,
inside an 8-minute window:

#	tool input size	sandbox_permissions on the wire	PreToolUse delivered	Result
A	115 B	no	yes	sandbox denied the write
B	382 B	yes (danger-full-access, as the host hint instructed)	no	write succeeded
C	84 B (read)	no	yes	succeeded

Between A and B the host appended [sandbox: escalation available ...] to the tool result, and
the model retried with the parameter. The parameter is filled in by the model, not injected by
the host; the escalation itself is genuinely enforced by the sandbox — without the parameter the
call is rejected every time. So between A and B the only thing that differs is whether
sandbox_permissions is present in the dispatched call.

From the hook side this is observable only as an absence, at PostToolUse time:

{"event":"PostToolUse","tool":"write","verdict":"clean",
 "trigger":"mtime","scanned":0,"p0":0,"targets":[],
 "pre_seen":false,"pre_missing":true,"pre_scope":"no_p0_target"}

pre_seen:false is recorded for any PostToolUse whose target is in scope but which has no
matching PreToolUse observation; pre_scope notes which early return suppressed it. That is
detection, not a fix: a PreToolUse gate cannot block a call it never receives.

Environment is the same as in the report: dsh 0.2.1-rc.2 (DSH Desktop) on Windows.

[argszero]

I checked the dispatch layer on 687f282e (the tree 0.2.1-rc.2 is cut from) and against the published artifacts, and the mechanism your root-cause section proposes cannot happen: a call carrying sandbox_permissions does reach the tools/pre-execute waterfall on this version. Stating the evidence so it can be attacked rather than believed.

There is exactly one path from a tool call to a tool body. ToolRuntime.execute (packages/core/tools/src/index.ts:1377) always enters prepareExecution (:1502), which runs the tools/pre-execute waterfall at :1513 before anything else; the body is reached only through dispatchScheduledExecution (:1613, the tools/execute waterfall) and dispatchToolBody (:1572), which has exactly one caller (:1615). Nothing else in the package calls it.

Escalation is resolved inside the tool body, strictly after that stage. The write path resolves its policy in resolvePolicy (packages/fs/tool-fs/src/sandbox.ts:87-105, calling approveEscalation at :97); the shell tools do it inside execute (packages/shell/tool-bash/src/index.ts:482-484); PTC does it inside its own execute (packages/core/tools/src/ptc.ts:393-397). All of these run after pre-execute has already returned.

The field is never read to decide dispatch. Across the tree, sandbox_permissions appears only in tool schemas, argument validation, and those approval calls. There is no conditional on it anywhere in the dispatch path — which agrees with your own asar scan that found zero skip predicates.

The PTC second-entry hypothesis is out too. Sub-dispatch goes through the same scheduler stage (ptc.ts:625-627 calls scheduler.dispatch(prepared.exec) on a preparation that already ran the policy pipeline), so even a tool call made from inside run_code gets pre-execute.

The shipped artifact matches the source. In the published @deepseek-ai/dsh-tools@0.2.1-rc.2 tarball, lib/index.js has one tools/pre-execute dispatch (:3321), dispatchToolBody (:3390), and its single caller inside the tools/execute waterfall (:3423-3427). The published @deepseek-ai/dsh-tool-fs resolves escalation in the same place (lib/index.js:1140).

So the observation stands as an observation, but the cause is downstream of dispatch. Two explanations fit your evidence and are testable from what you already have:

1. Attribution, not absence. Your own addendum notes 2495 of 2559 PreToolUse rows carry no tool_use_id. A per-id join therefore reports a gap whenever the Pre record for an escalated call landed without the id — and the escalated payloads are the larger ones (116 → 364 bytes; the pwsh case 1051 bytes), which is where a 240-character truncation and a payload-shape-dependent hook would bite. The decisive check is not the ledger: have the Pre hook write the payload's own tool_use_id together with its own timestamp to a raw file, then read that file per call instead of joining rows.
2. The Pre hook not completing for the larger payload. Check the exit status and stderr of the two configured Pre entries at those exact timestamps. A Pre hook that exits non-zero or hits its timeout would produce no record, and your ledger would show the same shape as a skipped dispatch.

What would not explain it: a tool-name matcher. The non-escalated write in the same session got PreToolUse, so the same name matched there.

If you can share the two hooks.json entries verbatim (command and matcher), I will reproduce the escalated-call path on this tree with an instrumented hook and report what the Pre payload actually carries. I would rather find the real cause than have this thread closed on a theory of mine that the dispatcher contradicts.

[SteelUnion]

This one matters to me directly, so I would rather understand the dispatch path than argue about the conclusion.

My plugin registers on tools/pre-execute and counts persistent operations. If calls carrying sandbox_permissions skip that waterfall, then the exact subset I care about, a model retrying an escalation it does not need, would be counted as if it never happened.

argszero says on 687f282 that the path cannot be reached at all, which would mean your four write calls and the two context calls went somewhere else entirely.

Is there a way to see which hook chain a given call actually went through? That would settle it without depending on either reading, and I would like to know rather than assume mine is safe.

You may already have that instrument. If so I would like to see what it prints.