Opening an issue first per CONTRIBUTING.md (feature ideas → discuss before implementation).
Idea: Add AWS Kiro CLI as a third agent runtime alongside Claude Code and Codex, through the existing YOKE adapter layer.
Why it fits YOKE: Kiro CLI exposes the Agent Client Protocol (ACP) via kiro-cli acp — standard JSON-RPC 2.0 over stdio, the same transport shape as the existing codex app-server integration. It maps cleanly onto the current adapter contract (init / createQuery / event streaming / permission routing / session resume).
Scope / footprint:
- New:
lib/yoke/adapters/kiro.js, lib/yoke/kiro-acp-server.js, lib/kiro-defaults.js
- Wiring mirrors every existing
codex touch-point (vendor factory, install/auth detection, client vendor toggle)
- No new npm dependencies — Kiro is detected on the system (
kiro-cli binary + whoami), not bundled
- GUI-only sessions, per-project adapter — same model as Codex
Status: Implemented and verified end-to-end against kiro-cli 2.7.0 (streaming, model switching, tool approve/deny, session resume) including on a mobile PWA. Happy to share the branch if you're open to it.
Understood that feature PRs aren't accepted by default — checking interest before proposing anything. Would a vendor-runtime addition like this be something you'd consider, or is the runtime set intentionally fixed?
Opening an issue first per CONTRIBUTING.md (feature ideas → discuss before implementation).
Idea: Add AWS Kiro CLI as a third agent runtime alongside Claude Code and Codex, through the existing YOKE adapter layer.
Why it fits YOKE: Kiro CLI exposes the Agent Client Protocol (ACP) via
kiro-cli acp— standard JSON-RPC 2.0 over stdio, the same transport shape as the existingcodex app-serverintegration. It maps cleanly onto the current adapter contract (init / createQuery / event streaming / permission routing / session resume).Scope / footprint:
lib/yoke/adapters/kiro.js,lib/yoke/kiro-acp-server.js,lib/kiro-defaults.jscodextouch-point (vendor factory, install/auth detection, client vendor toggle)kiro-clibinary +whoami), not bundledStatus: Implemented and verified end-to-end against
kiro-cli2.7.0 (streaming, model switching, tool approve/deny, session resume) including on a mobile PWA. Happy to share the branch if you're open to it.Understood that feature PRs aren't accepted by default — checking interest before proposing anything. Would a vendor-runtime addition like this be something you'd consider, or is the runtime set intentionally fixed?