feat(sdk): add extensions option to both SDKs

[juhuan]

Summary

Add extensions option that maps to CLI's --extensions (-e) flag, allowing users to specify which extensions to load for a session. If not provided, all extensions are used.

• Python SDK: extensions: list[str] | None in QueryOptions, mapped to --extensions (comma-separated)
• TypeScript SDK: extensions?: string[] in TransportOptions and QueryOptions, with Zod schema validation

Test plan

• Python SDK tests pass (pytest — 58 passed)
• TypeScript SDK typecheck passes (tsc --noEmit)
• TypeScript SDK tests pass (vitest run — 1163 passed)

[qwen-code-ci-bot]

[Suggestion] The new extensions option is not covered by any test in packages/sdk-python/tests/unit/test_transport.py. The existing test_build_cli_arguments_maps_supported_options test covers all analogous options (core_tools, exclude_tools, allowed_tools) but extensions is absent from both the QueryOptions(...) constructor call and the expected args list.

Consider adding extensions=["ext-a", "ext-b"] to the test's QueryOptions and asserting "--extensions", "ext-a,ext-b" in the expected args, mirroring the pattern used for the other list options.

— qwen3.7-max via Qwen Code /review

[qwen-code-ci-bot]

[Suggestion] The new extensions option is not covered by any test in packages/sdk-typescript/test/unit/ProcessTransport.test.ts. The existing test that exercises coreTools and excludeTools (around line 194) does not include extensions in the TransportOptions or the expected args.

Consider adding extensions: ['ext-a', 'ext-b'] to the test's TransportOptions and asserting '--extensions', 'ext-a,ext-b' in expect.arrayContaining([...]), mirroring the pattern used for the other list options.

— qwen3.7-max via Qwen Code /review

[doudouOUC]

qwen-code review summary

PR #6470 adds an extensions option to both the Python and TypeScript SDKs, mapping to the CLI's --extensions flag. The implementation is correct, minimal, and follows the same patterns used by existing list options (allowedTools, coreTools, etc.). No bugs or security issues in the diff itself.

Findings

[Suggestion] Missing test coverage for extensions in both SDKs — packages/sdk-python/tests/unit/test_transport.py, packages/sdk-typescript/test/unit/ProcessTransport.test.ts

• The existing transport tests cover every other list option (core_tools, exclude_tools, allowed_tools, auth_type) but extensions was added without any corresponding test assertion.
• A future refactor could silently drop --extensions from CLI invocation with no test catching it.
• Fix: Add extensions=["my-ext"] to existing test inputs and assert "--extensions", "my-ext" appears in output.

Needs Human Review

Possibly: Argument injection via flag-like extension names — If an SDK consumer passes untrusted extension names (e.g., ["--yolo"]), yargs may parse the flag-like string as a separate CLI option rather than as an extension name value. However, this is the exact same pattern used by allowedTools/coreTools/excludeTools across all SDKs — not introduced by this PR. Low practical risk since extension names are validated against loaded extensions on the CLI side.

Verdict

Comment — Clean, correct implementation. Tests would be nice but aren't blocking.

[wenshao]

💡 Suggestion: Consolidate SDK PRs

Hi @juhuan, thanks for the comprehensive SDK work! We noticed you have 15 open PRs that all modify the same core files (transport.py, types.py, queryOptionsSchema.ts, types.ts, ProcessTransport.ts, createQuery.ts) and were created on the same day.

The problem

• Merge conflicts: Since all 15 PRs touch the same files, whichever merges first will cause conflicts in the remaining 14.
• Review overhead: Reviewing 15 near-identical PRs separately is inefficient and risks fatigue.
• CI cost: 15 separate CI runs for the same lint/typecheck passes.

Suggestion: regroup into 2 PRs

We recommend closing the current 15 PRs and reopening them as 2 consolidated PRs:

PR 1 — feat(sdk): expose transport and query options in both SDKs

Covers pure SDK-side option additions (~9 current PRs):

• disabled_slash_commands (feat(sdk): add disabled_slash_commands option to Python and TS SDKs #6480)
• sandbox, safe_mode, insecure, worktree CLI flags (feat(sdk): expose sandbox, safe_mode, insecure, worktree CLI flags #6479)
• fallback_model and proxy options (feat(sdk): add fallback_model and proxy options to Python and TS SDKs #6478)
• allowed_mcp_server_names (feat(sdk): add allowed_mcp_server_names option to both SDKs #6474)
• extensions option (feat(sdk): add extensions option to both SDKs #6470)
• extra_args option (feat(sdk): add extra_args option to both SDKs #6469)
• include_directories option (feat(sdk): add include_directories option to both SDKs #6468)
• sub-agent support / maxSubagentDepth (feat(sdk): add sub-agent support to Python SDK and maxSubagentDepth to both SDKs #6467)
• max_tool_calls option (feat(sdk): expose max_tool_calls option in Python and TypeScript SDKs #6461)
• mcp_servers support (feat(sdk-python): enable mcp_servers support via initialize control request #6463)
• fork_session option (feat(sdk): expose fork_session option in Python and TypeScript SDKs #6458)

PR 2 — feat(sdk): add control request methods to both SDKs

Covers features that also involve CLI-side ControlDispatcher changes (~4 current PRs):

• reasoning_effort option (feat(sdk): add reasoning effort option to CLI and both SDKs #6464)
• get_usage_info() control request (feat(sdk): add get_usage_info() control request to CLI and both SDKs #6473)
• get_context_usage() method (feat(sdk-python): add get_context_usage() method #6471)
• get_available_models() method (feat(sdk): add get_available_models() to Python and TypeScript SDKs #6460)

This keeps a reasonable separation of concerns while eliminating the merge-conflict chain and making review much more manageable.

/cc @juhuan

[wenshao]

Closing in favor of consolidated PRs (see suggestion comment above). Please reopen as 2 grouped PRs.