[Bug] [tools].disabled is ignored by the default terminal CLI

What version of Kimi Code is running?

0.31.1

Which open platform/subscription were you using?

N/A — custom OpenAI-compatible provider (not using /login)

Which model were you using?

Custom OpenAI Responses model

What platform is your computer?

Darwin 27.0.0 arm64 arm

What issue are you seeing?

[tools].disabled is ignored on the default CLI path (v1) in Kimi Code 0.31.1.

With this config:

[tools]
disabled = ["Bash"]

the matching llm.tools_snapshot still includes the top-level Bash tool. The model-facing Agent tool description also still lists Bash for subagent profiles. kimi doctor reports that the config is valid.

With the same config and KIMI_CODE_EXPERIMENTAL_FLAG=1, the v2 engine removes Bash from both the top-level tool list and the subagent Tools: lines.

The original symptom involved disabled = ["WebSearch"], but logout can independently prevent WebSearch from being registered. The Bash case above avoids that provider-related ambiguity and reproduces the policy problem in both the top-level tool list and the Agent description.

What steps can reproduce the bug?

1. Add this to config.toml before starting Kimi Code:

   [tools]
   disabled = ["Bash"]
   

2. Confirm the file is accepted:

   kimi doctor
   

3. Make sure KIMI_CODE_EXPERIMENTAL_FLAG is unset, then start a fresh CLI process:

   kimi -p 'Reply exactly OK. Do not call tools.'
   

4. In that session's wire.jsonl, take the final loop llm.request.toolsHash and inspect the llm.tools_snapshot with the matching hash.

5. Observe that .tools[].name still contains Bash, and the Agent tool description still includes Bash in its subagent Tools: lines.

6. Run the same command as a v2 control:

   KIMI_CODE_EXPERIMENTAL_FLAG=1 kimi -p 'Reply exactly OK. Do not call tools.'
   

Observed on 0.31.1:

default v1: Bash in top-level tools = yes; Bash in Agent description = yes
v2 control:  Bash in top-level tools = no;  Bash in Agent description = no

What is the expected behavior?

[tools].disabled should work on the default CLI path as documented. A disabled built-in tool should not be sent to the model or listed in model-facing subagent descriptions. This should not require opting into the experimental v2 engine.

Additional information

The source appears to match the observed engine split:

• apps/kimi-code/src/cli/experimental-v2.ts keeps the CLI on v1 unless KIMI_CODE_EXPERIMENTAL_FLAG is truthy.
• packages/agent-core-v2/src/agent/toolPolicy/ implements the global [tools] policy, and the v2 control applies it correctly.
• I could not find equivalent global [tools] policy integration in packages/agent-core. Its packages/agent-core/src/tools/builtin/collaboration/agent.ts builds the v1 subagent description from profile tools / disallowedTools.

The documentation says the global tools switch applies to every agent in all sessions and shapes the tools shown to the model: docs/en/configuration/config-files.md (tools section).

Related but not a duplicate: #2421 concerns MCP tools merged into the request after filtering. This report concerns built-in tools on the default v1 CLI path; the v2 control behaves correctly.

Start with apps/kimi-code/src/cli/experimental-v2.ts and compare the v1 path with packages/agent-core-v2/src/agent/toolPolicy/ and packages/agent-core/src/tools/builtin/collaboration/agent.ts. Reproduce with kimi doctor and the two kimi -p commands, then verify in wire.jsonl that disabled built-in tools are absent from the top-level snapshot and model-facing Agent descriptions on the default path.