fix(kiro): use CLI wire contract without profiles - #694
Conversation
Co-authored-by: OpenAI Codex <codex@openai.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughKiro adapter requests now distinguish CLI and IDE callers. CLI requests receive dedicated headers and conversation metadata, while IDE requests retain their existing origin and profile behavior. Tests cover CLI, API-key, OAuth, and conversation-history contracts. ChangesKiro CLI and IDE wire contracts
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant KiroClient
participant createKiroAdapter
participant buildKiroPayload
participant KiroAPI
KiroClient->>createKiroAdapter: build request
createKiroAdapter->>createKiroAdapter: select CLI or IDE wireClient
createKiroAdapter->>buildKiroPayload: buildKiroPayload(..., wireClient)
buildKiroPayload-->>createKiroAdapter: caller-specific conversation payload
createKiroAdapter->>KiroAPI: send headers and payload
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 28996a4cfb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "x-amz-target": AMZ_TARGET, | ||
| "user-agent": kiroCliUserAgent(true), | ||
| "x-amz-user-agent": kiroCliUserAgent(false), | ||
| "x-amzn-codewhisperer-optout": "false", |
There was a problem hiding this comment.
For every profile-less Builder ID or Kiro API-key request, this branch changes the previously sent x-amzn-codewhisperer-optout value from true to false. This silently reports that the user has not opted out of CodeWhisperer data collection even though ocx exposes no setting or consent flow for that reversal; keep the header at true unless an explicit user preference enables participation.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 9b5b827. CLI-shaped requests now preserve x-amzn-codewhisperer-optout: true. Verified with the focused Kiro suite and a live profile-less Builder ID request (HTTP 200).
| if (wireClient === "cli") { | ||
| currentUim.userInputMessageContext = { | ||
| ...(currentUim.userInputMessageContext ?? {}), | ||
| envState: { operatingSystem: kiroCliPlatform(), currentWorkingDirectory: process.cwd() }, |
There was a problem hiding this comment.
When the persistent proxy starts from project A and later serves a request from project B—or runs as a background service or for a remote client—process.cwd() and process.platform describe the proxy process, not the requesting Codex client's workspace and OS. The CLI-shaped payload therefore gives Kiro stale or incorrect environment state, which can make generated tool paths and shell commands target the wrong project while also disclosing an unrelated local path; propagate trusted per-request client metadata or use neutral values instead.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 9b5b827. The adapter no longer sends proxy-process envState; no client workspace or OS is fabricated or disclosed. A live profile-less Builder ID request without envState returned HTTP 200.
| const profileArn = resolveKiroProfileArn(parsed._kiroAuthContext); | ||
| // Builder ID and Kiro API keys have no profile ARN and are accepted only on Kiro's CLI | ||
| // request path. Enterprise profiles retain the existing IDE-shaped request. | ||
| const wireClient: KiroWireClient = profileArn ? "ide" : "cli"; |
There was a problem hiding this comment.
When a custom Kiro API-key provider is used while KIRO_PROFILE_ARN is set or the local Kiro CLI database contains a profile ARN, resolveKiroProfileArn() returns that unrelated profile and this condition selects the IDE contract solely because it is nonempty. The resulting ksk_ request includes the profile ARN and omits the tokentype: API_KEY header, so authentication is sent using the exact contract this change says API keys cannot use; determine API-key status first and ignore profile metadata for those credentials.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 9b5b827. ksk_ detection now precedes wire-client selection, forces CLI mode, and clears resolved profile metadata. The regression test supplies an unrelated profile ARN and asserts that neither the header nor payload contains it while tokentype: API_KEY remains present.
Co-authored-by: OpenAI Codex <codex@openai.com>
…ion hardening, Windows scheduler fixes Promotes dev to main for the v2.7.43 quick-fix release: - fix(gui): renew loopback dashboard sessions silently instead of prompting - PR #705 + follow-up: Claude effort restoration boundary hardening - PRs #694/#698/#699 and Windows scheduler compare/denial fixes
Summary
API_KEYtoken type only where required.This fixes profile-less Builder ID requests being routed through the IDE contract, where the service expects a profile ARN. The request shape is based on an observed Kiro CLI request.
Verification
bun test tests/kiro-images.test.ts tests/kiro-stream.test.ts tests/kiro-adapter.test.ts tests/kiro-review-regressions.test.ts tests/kiro-retry.test.ts tests/kiro-oauth.test.ts(225 passed)bun run typecheckbun run privacy:scanbun run test(5,900 passed, 1 Windows-only test skipped, 0 failed)Checklist
tokentype: API_KEYis added only forksk_credentials.Summary by CodeRabbit