[li-xiu-qi]

Problem

Fixes #327.
Fixes #239.
Supersedes #317.

In approve-for-me, the permission policy heuristically scans command, cmd, and script fields for every tool. This misclassifies shell-like text inside the built-in workflow JavaScript sandbox as a host shell command. For example, a workflow source string containing rm -rf can trigger shell confirmation or denial even though the workflow does not execute that text as a shell command.

The root cause is that command analysis has no registration provenance: it cannot distinguish a first-party structured tool from an external tool whose parameters still require conservative inspection.

The closed, unmerged #317 addressed the immediate workflow.script false positive with a name-based NON_SHELL_SCRIPT_TOOLS exemption. It was closed in favor of the provenance-based approach proposed in #327. This PR implements that approach and also covers the original #239 report without adding an extension-name whitelist to the core permission policy.

Changes

• Add optional ToolOrigin provenance (core, builtin, extension, or mcp) to tool definitions and tool_call events, and propagate the registered origin to permission evaluation.
• Tag the core tool profile and first-party capability bundle at registration. Core and built-in tools run shell analysis only for run_command, bash, and powershell; other structured inputs are not reinterpreted as shell commands.
• Preserve conservative scanning for MCP, extension, and unknown-origin calls. Disk extensions and ordinary SDK customTools cannot self-assign a trusted tier. Host-injected createStepToolProfile definitions retain core provenance through an object-identity marker without changing tool object identity.
• Keep explicit tool denials, dedicated-shell analysis, and then_run verification unchanged. Add permission, registration, SDK, MCP, and real agent-loop workflow coverage, plus extension and SDK documentation.

Behavior and compatibility

The public interface changes are additive and optional: existing tool definitions and event consumers require no migration, and no configuration or persisted-session format changes are introduced.

Existing extensions, ordinary SDK custom tools, MCP tools, and calls without provenance retain the previous conservative heuristic behavior. First-party workflow and other non-shell built-in capabilities no longer receive irrelevant shell analysis. Trusted shell tools and then_run commands still undergo command policy checks, and explicit tool overrides still take precedence.

Validation

Windows, Node.js 24:

• pnpm check — passed, including formatting, linting, type checking, and repository boundary checks.
• cd packages/coding-agent && pnpm exec vitest run --pool=forks test/tool-origin-permissions.test.ts — 17 passed.
• cd packages/coding-agent && pnpm exec vitest run --pool=forks test/step-then-run-command-parity.test.ts — 12 passed.
• cd packages/coding-agent && pnpm exec vitest run --pool=forks — compared with a pristine upstream/main baseline. This exposed three then_run object-identity regressions during development; those were fixed and the suite now passes independently. The remaining parallel-run failures were rerun separately where relevant.
• ./test.sh — the candidate and pristine baseline both stop at the same existing Windows release-bundle failure: 35 script tests passed and 1 failed (install.sh persists inherited PATH and preserves malformed user blocks). Consequently, this entrypoint did not complete the repository package-test phase locally.
• GitHub CI on final commit f7386db5 — build-check-test and Check commit attribution passed (run 41030952095).

Limitations

The local Windows full-suite result is not clean on either the candidate or pristine baseline. One unrelated CLI completion-check rerun also hit spawnSync ETIMEDOUT; the affected origin, MCP, workflow, and then_run suites pass independently. No interactive terminal approval UI was manually exercised; the workflow regression is covered through the real agent-loop test harness.