What feature would you like to see?
Summary
Kimi Code is already a very impressive agent system, especially considering it is still pre–v1.0.0. The overall architecture, session handling, and IDE integration are well-designed and highly usable.
However, there is currently a critical limitation when using Kimi Code as an external ACP agent inside modern IDEs (such as Zed):
❌ Multi-root workspace (Additional Directories / Additional Workspace Roots) is not supported.
This significantly impacts real-world usability in multi-repository development environments.
Problem Description
When using Kimi Code in IDEs that support multi-root workspaces (e.g. Zed, VS Code workspaces, JetBrains projects), the following issue occurs:
“This agent doesn't currently support multi-root workspaces. It currently only operates by default on 'xxxxx'.”
As a result:
- The agent only has access to the first root directory
- All additional workspace roots are ignored
- File operations (
read/write) are restricted to a single directory scope
- Cross-repository workflows are broken
This severely limits productivity in real-world development setups where multi-repo workspaces are standard.
Root Cause
According to the ACP specification:
📄 https://agentclientprotocol.com/protocol/v1/session-setup#additional-workspace-roots
The ACP protocol already defines support for:
Additional Directories / Additional Workspace Roots
This feature became Completed on June 1, 2026 as part of the ACP RFD lifecycle.
However, Kimi Code currently does not implement this part of the session setup protocol, which leads to IDEs disabling multi-root functionality entirely.
Impact
This limitation affects:
1. Multi-repository development
- Monorepos with linked external repos
- Microservice architectures
- Plugin-based systems
2. IDE integration (especially Zed)
- External agent mode falls back to single-root mode
- Workspace context is incomplete
- Tooling behaves inconsistently
3. File system tools
fs/read_text_filefs/write_text_file
Only operate within a single root directory, which breaks expected ACP behavior.
Expected Behavior
Kimi Code should support ACP-defined equivalent:
- Additional workspace roots must be recognized at session initialization
- File system tools must resolve paths across all roots
- IDE should NOT restrict agent to a single directory
Why This Matters
ACP explicitly designed this feature to support:
- modern multi-repo development
- plugin-based architectures
- distributed service repositories
Without it, Kimi Code behaves like a single-folder acp agent, which is increasingly incompatible with real-world workflows.
Additional Notes
Kimi Code is already a very strong agent implementation, even before reaching v1.0.0.
Supporting ACP multi-root workspaces would significantly improve:
- IDE compatibility
- enterprise usability
- agent context correctness
- developer experience in real-world codebases
Additional information
No response
What feature would you like to see?
Summary
Kimi Code is already a very impressive agent system, especially considering it is still pre–v1.0.0. The overall architecture, session handling, and IDE integration are well-designed and highly usable.
However, there is currently a critical limitation when using Kimi Code as an external ACP agent inside modern IDEs (such as Zed):
This significantly impacts real-world usability in multi-repository development environments.
Problem Description
When using Kimi Code in IDEs that support multi-root workspaces (e.g. Zed, VS Code workspaces, JetBrains projects), the following issue occurs:
As a result:
read/write) are restricted to a single directory scopeThis severely limits productivity in real-world development setups where multi-repo workspaces are standard.
Root Cause
According to the ACP specification:
📄 https://agentclientprotocol.com/protocol/v1/session-setup#additional-workspace-roots
The ACP protocol already defines support for:
This feature became Completed on June 1, 2026 as part of the ACP RFD lifecycle.
However, Kimi Code currently does not implement this part of the session setup protocol, which leads to IDEs disabling multi-root functionality entirely.
Impact
This limitation affects:
1. Multi-repository development
2. IDE integration (especially Zed)
3. File system tools
fs/read_text_filefs/write_text_fileOnly operate within a single root directory, which breaks expected ACP behavior.
Expected Behavior
Kimi Code should support ACP-defined equivalent:
Why This Matters
ACP explicitly designed this feature to support:
Without it, Kimi Code behaves like a single-folder acp agent, which is increasingly incompatible with real-world workflows.
Additional Notes
Kimi Code is already a very strong agent implementation, even before reaching v1.0.0.
Supporting ACP multi-root workspaces would significantly improve:
Additional information
No response