feat(sdk): add disabled_slash_commands option to Python and TS SDKs

[juhuan]

Summary

• Add disabled_slash_commands (Python) / disabledSlashCommands (TS) option mapping to CLI's --disabled-slash-commands flag
• Slash command names to hide/disable, matched case-insensitively against the final command name
• Implemented in both Python SDK (types, transport) and TS SDK (types, schema, transport, createQuery)
• Unit tests added for both SDKs

Test plan

• Python SDK unit tests pass (35 tests)
• TS SDK unit tests pass (75 tests)
• --disabled-slash-commands flag present in CLI args with comma-separated values

[qwen-code-ci-bot]

Hey @juhuan — thanks for the PR! The code changes look clean and focused — adding disabledSlashCommands / disabled_slash_commands to both SDKs is a straightforward wiring job, and the implementation follows existing patterns well.

However, the PR body doesn't follow the PR template. Most required sections are missing:

• What this PR does — PR has "Summary" instead
• Why it's needed — no motivation or problem statement
• Reviewer Test Plan (How to verify, Evidence Before/After, Tested on table) — PR has a minimal "Test plan" with checkboxes but not the structured format
• Risk & Scope — missing
• Linked Issues — missing
• 中文说明 — missing

Could you restructure the PR body to match the template? This helps maintainers review efficiently and understand the context at a glance. Happy to help if anything is unclear.

中文说明

你好 @juhuan — 感谢提交 PR！代码改动本身很简洁，在两个 SDK 中添加 disabledSlashCommands / disabled_slash_commands 的实现也遵循了现有模式。

不过，PR 正文没有遵循 PR 模板，大部分必填部分缺失：

• What this PR does — PR 用的是 "Summary"
• Why it's needed — 缺少动机或问题描述
• Reviewer Test Plan（验证方法、前后对比、测试平台）— PR 只有一个简单的 "Test plan" 复选框
• Risk & Scope — 缺失
• Linked Issues — 缺失
• 中文说明 — 缺失

能否按照模板重新组织 PR 正文？这样有助于维护者快速理解和审查。如有疑问随时沟通。

— Qwen Code · qwen3.7-max

[qwen-code-ci-bot]

[Critical] The @example ['/init', '/vim'] uses slash-prefixed names, but the CLI matches against bare command names ('init', 'vim'). The yargs coerce and addDisabled functions never strip a leading /, so '/init' will never match 'init' — commands will silently remain enabled.

Verified at both matching sites (CommandService.create and nonInteractiveCliCommands.ts): they compare against cmd.name.toLowerCase() where cmd.name is the bare name (e.g., 'init' in initCommand.ts, 'vim' in vimCommand.ts). The official CLI docs in docs/users/configuration/settings.md correctly use bare names: "disabled": ["auth", "mcp"].

Suggested change

	*/
	* @example ['init', 'vim']

Alternatively, strip the leading / in both SDK transports before joining, since users will naturally think in /command terms.

— qwen3.7-max via Qwen Code /review

[qwen-code-ci-bot]

[Suggestion] Test values ["/init", "/vim"] use slash-prefixed names, but the CLI expects bare names ('init', 'vim'). This propagates the incorrect format as test-as-documentation — developers reading this test will copy the slash-prefixed format.

Suggested change

	idx = args.index("--disabled-slash-commands")
	QueryOptions(disabled_slash_commands=["init", "vim"])

Also update the assertion:

    assert args[idx + 1] == "init,vim"

— qwen3.7-max via Qwen Code /review

[qwen-code-ci-bot]

[Suggestion] Test values ['/init', '/vim'] use slash-prefixed names, but the CLI expects bare names ('init', 'vim'). This propagates the incorrect format as test-as-documentation.

Suggested change

	disabledSlashCommands: ['init', 'vim'],

Also update the assertion:

        expect.arrayContaining(['--disabled-slash-commands', 'init,vim']),

— qwen3.7-max via Qwen Code /review

[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.