fix(claude-agent-sdk): stop denied native tool calls from burning Opus sessions

[ddotz]

Summary

The Claude Agent SDK adapter intentionally sets permissionMode: "dontAsk" and makes canUseTool always deny native Claude Code tools, expecting execution to go through Senpi's in-process MCP custom-tools pipeline.

In OMO/Senpi task runs, the model can still select native Bash. That call is denied, and the outer continuation path treats the resulting shutdown as unfinished work. It creates another external SDK/Opus session and replays the full serialized task context. This repeats until the account hits its session/token limit.

Observed evidence

• Every affected child session has entrypoint: "sdk-ts", promptSource: "sdk", and userType: "external".
• The affected sessions start in permissionMode: "dontAsk".
• Native Bash calls return Permission to use Bash has been denied.
• The session then records interruptedByShutdown: true; the continuation starts a fresh Opus session.
• Replayed prompts were about 300k characters per session.

Why this appears to be an adapter gap

Commit 5fd13840785a65d5d8b34528843b20709b195e8e explicitly documents that native tool calls are denied while Senpi executes through its own pipeline. The failure path above lets a denied native call escape into continuation/retry instead of executing the equivalent custom tool or returning a terminal failure to the parent.

Expected behavior

1. The SDK agent should reliably use mcp__custom-tools__* for executable tools, or native tools should be routed through the Senpi permission pipeline.
2. A native-tool denial, permission rejection, user interrupt, shutdown, or provider-limit error must be terminal to the current continuation; it must not create a new provider session automatically.
3. If an actual retry is appropriate, resume the existing SDK session rather than replaying the whole task transcript into a fresh Opus session.

Impact

This can exhaust an Anthropic account by repeatedly opening Opus sessions for a task that cannot execute its first Bash command.

[ddotz]

Incident data: what actually burned, and why (+ fix verified locally)

Follow-up with full transcript archaeology, a live repro, and local verification of a fix. Environment: senpi 2026.7.29, bundled @anthropic-ai/claude-agent-sdk 0.3.220, macOS arm64.

What happened (2026-07-29, 22:55–23:18 KST)

During a single 23-minute working session, the adapter created 70 CLI-side Claude Code sessions under one ~/.claude/projects/<cwd>/ directory — roughly one every 20 seconds — until the account hit its session limit:

• Transcript file sizes grew monotonically 42KB → 427KB: every new session re-sent everything the previous ones had, plus one more turn.
• Every session's first user message = a 29,051-byte injected <ultrawork-mode> prompt + the full serialized conversation history, replayed from scratch.
• Every session then recorded the same internal pattern (e.g. session fd1b7c1d):

tool_use mcp__custom-tools__eval
  → err: "Permission to use mcp__custom-tools__eval has been denied because
     Claude Code is running in don't ask mode. IMPORTANT: You *may* attempt
     to accomplish this action using other tools..."
tool_use Bash   ← model retries, as the deny text instructs
  → err: "Permission to use Bash has been denied..."
[Request interrupted by user]
→ next session created, with an even longer replay

So the cost per turn was: (full history + 29KB prompt replay) × (1 original API call + 1 deny-induced retry call), × 70 turns, compounding as the history grew.

Why it happened

The adapter uses the SDK as inference-only: permissionMode: "dontAsk" (options.ts) plus an always-deny canUseTool (tools.ts), intercepts tool_use from the stream, interrupts, executes the tool in-process, and replays the whole context into a fresh query() for the next turn (stream.ts). One new CLI session per turn is therefore by design — but three defects turn it into a burner:

1. The dontAsk deny text incites a retry, and it lands before the interrupt does. The early-stop in stream.ts waits for message_stop; the CLI's denial ("You may attempt … other tools") reaches the model first, the model retries with another native tool, and that retry is a full-context API call senpi discards. This is the eval→Bash pattern present in the affected sessions.
2. canUseTool is dead code. Reproduced against the raw SDK with the adapter's exact options: canUseTool invoked 0 times — the CLI's own dontAsk denial fires first, so the adapter's intended terminal deny message never reaches the model.
3. Nothing bounds the replay. Each turn re-sends the entire history plus the 29KB injected prompt; after any cache-cold restart the full prompt is re-billed at raw input price.

Mitigation already attempted: allow rules do not reach this path

After the incident I granted allow permissions at both layers — neither changes anything, verified by re-probing afterwards:

• ~/.senpi/agent/settings.json → "permission": { "*": "allow" } — this gates senpi's in-process tool execution only; the CLI-side dontAsk denial happens in the spawned Claude Code process before senpi ever executes anything, so the deny→retry→interrupt cycle is unchanged.
• ~/.claude/settings.json → full permissions.allow Bash rule list — never loaded at all, because the adapter spawns the CLI with settingSources: [] (options.ts / resolveSettingSources).

With both in place, a fresh probe today still produces the identical CLI-side transcript. There is no user-side configuration that can stop this; it has to be fixed in the adapter.

Live repro (clean scratch dir)

senpi -p --provider claude-agent-sdk --model claude-opus-5 "use the bash tool to run exactly: touch /tmp/x/probe2.txt; echo touched" → CLI transcript shows Bash denied with the same inciting message → interrupt → new session; senpi executes the command itself and the run "succeeds", so every native tool call in normal use pays the deny/replay cost silently.

Bonus hole found while probing: "echo … && pwd" matches Claude Code's built-in safe-command handling, which bypasses the dontAsk denial — the CLI actually executed it (toolUseResult with real stdout in the transcript) and senpi executed it again after interception → double execution of any command matching the safe set.

Requested fix

1. Gate native tools with a PreToolUse hook (Bash|Write|Edit|Read|Grep|Glob) denying with a terminal, non-inciting message. Hooks run before every execution in every permission mode — this removes the retry amplification and closes the safe-command double-execution hole, neither of which dontAsk rules or canUseTool can reach.
2. Interrupt earlier — on message_delta (stop_reason: "tool_use") rather than message_stop — to shrink the window in which the CLI can start its next internal API call.
3. Bound the replay — reuse/resume the existing SDK session where possible instead of replaying the entire transcript into a fresh session every turn (per Expected behavior 3 in the OP); at minimum, avoid re-sending large injected prompts verbatim on every turn.
4. Remove or repurpose the now-dead canUseTool deny.

Fix 1 verified locally (raw SDK, adapter-equivalent options)

Adding only the PreToolUse deny hook on top of the adapter's current options eliminates both failure modes:

scenario	current (dontAsk denial)	with PreToolUse deny hook
touch …; echo (non-safe)	Bash denied → model retries with Write → denied; 3 turns, 2 tool_uses	1 tool_use, 0 retries, 2 turns; model ends turn: "Command has been submitted for execution by the host."
echo … && pwd (safe-listed)	CLI executes for real (toolUseResult present) → double execution with the host	hook fires before safe-command handling → no CLI-side execution, no retry

canUseTool remained at 0 invocations in every run, confirming point 4.

Verification script (dontAsk + PreToolUse deny hook)

import { query } from "@anthropic-ai/claude-agent-sdk";

let hookCalls = 0;
let canUseToolCalls = 0;

const q = query({
  prompt: "Use the Bash tool to run exactly this one command: touch /tmp/probe.txt; echo done",
  options: {
    cwd: "/tmp",
    model: "sonnet",
    tools: ["Read", "Write", "Edit", "Bash", "Grep", "Glob"],
    permissionMode: "dontAsk",
    settingSources: [],
    systemPrompt: { type: "preset", preset: "claude_code" },
    canUseTool: async () => {
      canUseToolCalls++;
      return { behavior: "deny", message: "Tool execution is unavailable in this environment." };
    },
    hooks: {
      PreToolUse: [
        {
          matcher: "Bash|Write|Edit|Read|Grep|Glob",
          hooks: [
            async (input) => {
              hookCalls++;
              return {
                hookSpecificOutput: {
                  hookEventName: "PreToolUse",
                  permissionDecision: "deny",
                  permissionDecisionReason:
                    "This tool call is captured and executed by the host. Do not retry with other tools; end the turn.",
                },
              };
            },
          ],
        },
      ],
    },
  },
});

for await (const m of q) { /* observe assistant / tool_result / result messages */ }
console.log({ hookCalls, canUseToolCalls }); // => { hookCalls: 1, canUseToolCalls: 0 }, single tool_use, no retry

Without the hook, the same prompt produces: Bash → denied → Write → denied → give-up (3 turns, canUseToolCalls: 0, file not created).

[ddotz]

Follow-up to the proposed hook matcher: it must also cover mcp__custom-tools__.*, not only the six native tool names.

The observed burn chain began with mcp__custom-tools__eval being denied, then the model followed the CLI's "try other tools" instruction and retried via native Bash. Custom MCP tools without native SDK equivalents (eval, todo, LSP tools, etc.) therefore need the same terminal pre-execution denial:

matcher: "Bash|Write|Edit|Read|Grep|Glob|mcp__custom-tools__.*"

I applied this matcher to the installed adapter and repeated the test through the actual senpi CLI:

• mutation probe (echo once >> file; wc -l < file): native Bash emitted once; the hook returned the terminal host-capture message; senpi executed it once; the file contained exactly one line; no model tool retry.
• safe-command probe (echo … && pwd): the hook returned the same denial before Claude Code's safe-command execution path; the CLI transcript contained no real stdout in toolUseResult; senpi executed the captured call normally and returned the result.

This confirms the matcher prevents both the MCP→native retry chain from the incident and the native safe-command double-execution hole, while preserving Senpi's stream-capture → in-process execution → replay path.

[ddotz]

Data for Requested fix 3: unbounded replay was the largest cost factor

Measured from the incident-evening transcripts (2026-07-29 KST), one session's first-message prompt over 28 minutes:

time (KST)	prompt bytes	<ultrawork-mode> copies	ulw share of prompt
23:28	167,725	21	15%
23:49	575,091	65	4%*
23:56	875,961	70	73% (637,732 B)

Each copy is a 24,871-byte block injected once per matching user input by the ultrawork extension (correct, conditional behavior) — then buildPromptBlocks() re-serializes the full message history every turn, so every past injection is re-sent forever and each additional one compounds. By 23:56 KST the prompt (~220K tokens) exceeded the model context window, and auto-compaction did not intervene during the error/model-churn window.

The replay-per-turn design itself is documented (providers.md: "senpi executes every tool itself"; session affinity "keeps Anthropic's prompt cache warm") and is cheap while the cache stays warm — but nothing bounds it once the cache goes cold (limit errors, account failover, provider switch), which is exactly the incident condition. The SDK already exposes resume / forkSession / resumeSessionAt; the adapter currently uses none of them.

Concrete ask: adopt resume for turn continuation, or at minimum dedupe repeated injected prompt blocks in buildPromptBlocks().

* the 4% figure at 23:49 is a measurement artifact (nested tags breaking the regex span); the copy-count series is the reliable one.

[ddotz]

Requested fix 3 follow-up: dedupe chosen over resume, implemented and verified locally

Between the two options I proposed for bounding the replay, resume turns out to be the wrong fit for this adapter, and block dedupe in buildPromptBlocks() the right one:

• resume inverts the documented stateless-bridge design ("senpi executes every tool itself"; senpi's session is the single source of truth for forking, compaction, steering, and mid-session model switches). A resumed CLI session would carry the interrupted deny artifacts the adapter deliberately discards, would miss turns served by other providers mid-session, and interacts badly with account failover.
• Dedupe keeps the design exactly as documented (full-history replay + prompt-cache warmth) and only stops re-sending byte-identical copies of large injected directive blocks — which was 73% of the 875,961-byte prompt in the incident data above.

Implementation (hot-patched into the installed dist, proposed for prompt-bridge.ts)

Post-process the built blocks: keep the first <ultrawork-mode>…</ultrawork-mode> occurrence, replace later byte-identical copies with a short marker; non-identical variants are left untouched.

function dedupeRepeatedDirectiveBlocks(blocks) {
    const OPEN = "<ultrawork-mode>";
    const CLOSE = "</ultrawork-mode>";
    const MARKER = OPEN + "[directive unchanged - identical to the first occurrence above]" + CLOSE;
    let first = null;
    for (const block of blocks) {
        if (block.type !== "text" || !block.text.includes(OPEN)) continue;
        const text = block.text;
        let out = "";
        let i = 0;
        let changed = false;
        for (;;) {
            const s = text.indexOf(OPEN, i);
            if (s === -1) { out += text.slice(i); break; }
            const e = text.indexOf(CLOSE, s + OPEN.length);
            if (e === -1) { out += text.slice(i); break; }
            const end = e + CLOSE.length;
            const span = text.slice(s, end);
            if (first === null) { first = span; out += text.slice(i, end); }
            else if (span === first) { out += text.slice(i, s) + MARKER; changed = true; }
            else out += text.slice(i, end);
            i = end;
        }
        if (changed) block.text = out;
    }
    return blocks;
}
// return blocks.length > 0 ? dedupeRepeatedDirectiveBlocks(blocks) : [{ type: "text", text: "" }];

Verification

Unit (synthetic context replaying the incident shape — three identical ~25KB ulw injections plus one different variant):

• full directive copies kept: 1; later identical copies replaced by markers: 2
• ulw payload 76,656 B → 25,788 B (the incident's 70-copy case scales to ~1.7 MB → ~25 KB + 69 markers)
• non-identical directive variant preserved verbatim; all user text preserved; contexts without the tag byte-identical to before
• cache-prefix stability holds: serializing the first N messages still yields an exact prefix of the full serialization, because replacement decisions depend only on earlier content — so Anthropic prompt-cache hits are unaffected

E2E smoke through the actual senpi CLI (claude-agent-sdk provider, opus) passes with the patched bridge: tool capture, in-process execution, and replay all behave normally.

Combined with the PreToolUse hook from the earlier comments (both running locally since 2026-07-30 KST), the remaining structural item for upstream is compaction/bound behavior during error churn, where auto-compaction failed to intervene in the incident window.