toolcraft: allow opting out of the built-in approvals tools (`approvals list`/`show`/`run`) in runCLI/runSDK/runMCP

[kamilio]

Summary

runCLI, runSDK, and runMCP in toolcraft unconditionally merge a built-in approvals group into the user's command tree via mergeApprovalsGroup. There is no option in RunCLIOptions / RunSDKOptions / RunMCPOptions (or HumanInLoopRuntimeOptions) to disable it.

For projects that don't use human-in-loop, the auto-injected group shows up in --help:

approvals                 Inspect and execute queued approvals.
  list [--state <string>]  List queued approvals.
  show --approval-id <string>  Show one approval.
  run --approval-id <string>  Run one queued approval.

…and there's no clean way to remove it. Today the only workaround is to monkey-patch the root with a getter/setter on children that filters the group back out after mergeApprovalsGroup re-adds it, which is obviously not great.

Repro

packages/toolcraft/src/cli.ts (and the equivalents in sdk.ts / mcp.ts):

const root = mergeApprovalsGroup(normalizeRoots(roots, process.argv));

There is no conditional or flag here.

Proposal

Add an opt-out to the run options, e.g.:

interface RunCLIOptions {
  // ...existing fields
  humanInLoop?: HumanInLoopRuntimeOptions | false;
  // or:
  approvals?: boolean; // default: true
}

When set to false, skip mergeApprovalsGroup (and the related confirm/HIL logic if appropriate). Equivalent flags should be honored in runSDK and runMCP.

Why

• Projects that wrap an OpenAPI client with no approval-gated commands shouldn't surface an approvals group to end users.
• Today the only escape hatch is fragile monkey-patching of root.children.

Happy to send a PR if the team agrees on the shape of the option.