feat(cli): wire execution permission controls

[B-A-M-N]

CLI execution permission controls and shell approval queue

Wires the SDK execution-permission controls into the CLI and adds a correlated shell-approval lifecycle. The CLI parses and forwards --no-shell, --ask-shell, --project-only, and --read-only. The approval bridge serializes concurrent requests FIFO and resolves active or queued requests as denied on timeout, abort, or UI shutdown.

PR branch and scope

• Target base: upstream main
• Head branch: security/1450-cli-integration-review-r2
• Head: ce39e6c2cb002927b73616e79fbc6ea69f74823b
• Depends on #1506 and #1530.
• Incremental diff from patch head 6611d08c6d6a1017f9a7fa9e12b48d5183883fac: 8 files, +540 / -2. Commits: 2bf7c3abd CLI wiring, 772958459 flag tests, and ce39e6c2c approval timeout/abort handling.
• Incremental compare.

GitHub does not support stacked pull requests across forks, so this follow-up targets upstream main; its displayed diff includes the prerequisite SDK and apply_patch changes until #1506 and #1530 are merged. The incremental compare above shows this follow-up's scope.

Verification

The complete stacked suite passed 98 tests across 9 files: 52 SDK tests, 35 CLI tests, and 11 common tests. The CLI regression files were run from the repository root because package-local startup references the absent cli/test/setup-scm-loader.ts preload. No typecheck diagnostic was reported in changed files.

Inference for this contribution was provided by FreeInference.org. FreeInference did not review, direct, approve, or otherwise participate in this work; all implementation, testing, and publication decisions are the contributor's own. If you find this useful, consider donating to FreeInference.org — they provide a useful and vital service.

[codebuff-team]

The core idea here is reasonable: wiring --no-shell/--ask-shell/--project-only/--read-only through to the SDK, and building a correlated shell-approval bridge (common/src/utils/shell-approval-bridge.ts) to fix the real bug that AskUserBridge silently drops concurrent requests. The bridge's FIFO/timeout/abort handling and its test coverage are solid work on their own.

But this PR is not reviewable as posted. The body says the actual contribution here is 8 files / +540/-2 (cli-args.ts, use-ask-user-bridge.ts, index.tsx, codebuff-client.ts, parsed-args.ts, and the bridge test), yet the diff GitHub shows is +2028/-15 across 16 files because it drags in the full sdk/src/permissions/execution-policy.ts module and its adversarial test suite from the still-unmerged #1506/#1530. That's over 1400 lines of security-sensitive sandboxing/symlink-resolution/path-containment code (isContainedPath, canonicalizePath, guardFileSystem) that a reviewer here can't evaluate independently of those PRs, and that this mirror can't safely accept standalone - the CLI flags here reference SDK options (noShell, shellApproval, etc.) that don't exist yet in this repo's SDK.

Concretely, as submitted:

• cli/src/utils/codebuff-client.ts passes noShell/askShell/projectOnly/readOnly/shellApproval into CodebuffClient, options that don't exist on CodebuffClient until feat(security): enforceable execution permissions for shell and filesystem access (#1450) #1506/fix(sdk): validate nested apply_patch targets #1530 land.
• There's no way to confirm the execution-policy semantics match what actually gets ported, since that code isn't itself under review here.

Please resubmit just the CLI-side diff (cli-args.ts, use-ask-user-bridge.ts, index.tsx, parsed-args.ts, codebuff-client.ts, and the shell-approval-bridge) once the SDK PRs it depends on are merged, so the diff matches what you describe as the actual change set. As-is this is too large and too entangled with unmerged work for a maintainer to safely port.