-
Notifications
You must be signed in to change notification settings - Fork 8
Description
Problem Statement
The current Qodo Command CLI is designed for single-shot terminal interactions, making it difficult to integrate with modern development environments that expect persistent, stateful agent connections via protocols like ACP (Agent Client Protocol). This limits Qodo's adoption in IDEs and developer tools that could benefit from its capabilities.
Background
I have successfully created a basic ACP adapter for Qodo Command that enables integration with the Zed editor. The adapter (available here) implements the Agent Client Protocol to bridge between:
- ACP Clients (like Zed editor) that speak JSON-RPC over stdio
- Qodo Command CLI tool that expects terminal interaction
Current Setup
Setting this up in the Zed editor requires minimal configuration:
{
"agent_servers": {
"Qodo Command": {
"command": "node",
"args": ["/full/path/to/qodo-acp-adapter/dist/index.js"],
"env": {
"QODO_PATH": "/usr/local/bin/qodo"
}
}
}
}
This makes Qodo command available as an agent directly in the editor.
Current Limitations with Examples
1. Verbose Tool Output
The current CLI outputs verbose tool call information that clutters conversations in ACP clients. It is also not easy to distinguish these messages from regular messages as they are all treated the same.
┌─ read_files
├── paths: package.json,README.md
└─── ✓ ✓ Success: [{"path": "package.json", "content": "..."}]
I have written a parser to partially deal with that so it now shows as:
Tool call: file_editor
Tool call: shell
Tool call: file_editor
But this is inadequate because it doesn't allow subsequent status updates for tool calls once they are completed or fail.
2. Session State Loss
Each command invocation loses context, making follow-up conversations impossible:
# First call
qodo "Fix the bug in main.py"
# Second call (loses context about what was just fixed)
qodo "Add tests for that fix" # ❌ Doesn't know what "that fix" refers to
3. Permission Management Challenges
The CLI requires permissions to be set upfront, but ACP clients expect dynamic permission requests:
- Tool requires file write permission
- User needs to approve in IDE
- No way to resume the command with elevated permissions
- Each invocation is a "one shot" with no state persistence
Proposed Enhancements
1. Session Management API
Add persistent session support:
qodo --session-id <id>
flag to maintain context across callsqodo --list-sessions
to manage active sessionsqodo --session-cleanup
for housekeeping- Session persistence for conversation history and context
Obviously this could be achieved in many different ways - the above is just one.
2. Structured Output Mode
Enable machine-readable responses:
qodo --output-format json
for structured responses- Separate tool calls from conversational output
- Progress indicators for long-running operations
- Configurable verbosity levels
Again this could be achieved in many different ways - the above is just one example.
3. Dynamic Permission System
Support runtime permission handling:
- API to query required permissions before execution
- Ability to pause and resume with elevated permissions
- Permission scoping (read-only, specific directories, etc.)
4. SDK/Library Interface
Provide programmatic access similar to Claude Code:
const qodo = new QodoSession();
const response = await qodo.chat("Fix this bug", {
permissions: ['file:write'],
sessionId: 'my-session'
});
Community Benefit
These enhancements would enable Qodo Command integration with:
- IDEs: Zed, Vim/Neovim plugins, IntelliJ family
- CI/CD: GitHub Actions, GitLab CI workflows, Jenkins pipelines
- Developer Tools: Custom automation scripts, development workflows
- ACP Ecosystem: Any tool supporting the Agent Client Protocol
- Build Systems: Integration with Webpack, Vite, and other dev servers
Comparison to Similar Tools
This approach follows successful patterns from:
- Claude Code: Provides both SDK and CLI, enabling rich IDE integrations
Technical References
Is there any apetite for this kind of improvement?