Repository navigation
Description
Client or integration
OpenCodex dashboard
Area
Authentication and account pool
Summary
On Windows, ocx login kiro does not import an existing Kiro CLI login. It reports that no kiro-cli token was found and falls back to manual access-token input, even though kiro-cli whoami confirms an active login.
I expected OpenCodex to import the local Kiro CLI session automatically, the same way it does for the other supported CLI token-store locations.
Root cause appears to be credential discovery: the Kiro credential lookup does not include the Windows Kiro CLI default SQLite path.
Reproduction
- Install Kiro CLI on Windows with the official installer (
irm 'https://cli.kiro.dev/install.ps1' | iex). - Run
kiro-cli loginand complete sign-in. - Confirm the session with
kiro-cli whoami, which prints the logged-in account. - Run
ocx provider add kiro. - Run
ocx login kiro. - Observe that the login prompts for a manual access token instead of importing the local CLI session.
Workaround that resolves it:
- Set the Windows Kiro CLI DB path as a persistent user environment variable:
[Environment]::SetEnvironmentVariable(
'KIROCLI_DB_PATH',
"$env:LOCALAPPDATA\Kiro-Cli\data.sqlite3",
'User'
)- Restart the proxy with
ocx restartso the server process picks up the new environment. - Run
ocx login kiroagain. It now succeeds without any manual token paste.
Note that setting the variable only in the calling shell is not enough, because the running proxy process performs the import and does not see the shell-local value.
The Windows Kiro CLI stores its auth database at:
%LOCALAPPDATA%\Kiro-Cli\data.sqlite3
That database has the expected shape, including an auth_kv row keyed kirocli:social:token and a state row keyed api.codewhisperer.profile.
Suggested fix: add %LOCALAPPDATA%\Kiro-Cli\data.sqlite3 to the Kiro credential discovery candidates alongside the existing macOS/Linux paths.
Version
2.7.42
Operating system
Windows 11 Pro 25H2 (10.0.26200)
Provider and model
kiro / kiro-auto
Logs or error output
> ocx login kiro
Opening browser for kiro login...
No kiro-cli token found. Paste a Kiro access token below (starts with 'aoa'). Otherwise install the Kiro CLI (`curl -fsSL https://cli.kiro.dev/install | bash`), run `kiro-cli login`, and retry - or set KIRO_ACCESS_TOKEN.
No kiro-cli token found. Paste a Kiro access token (starts with 'aoa'), or install the Kiro CLI and run `kiro-cli login` first.
Paste redirect URL or code (or wait for browser):
# after setting KIROCLI_DB_PATH and running `ocx restart`
> ocx login kiro
Logged in via an existing local CLI/keychain token - no browser needed.
Logged in to kiro.
> ocx status
OAuth logins:
kiro logged inRedacted configuration
{
"providers": {
"kiro": {
"adapter": "kiro",
"baseUrl": "https://runtime.us-east-1.kiro.dev",
"authMode": "oauth",
"defaultModel": "kiro-auto"
}
}
}Checks
- I searched existing issues and documentation.
- I removed secrets, tokens, account details, request credentials, and personal data.
Activity
github-actions commentedon Jul 29, 2026
Automated translation bookkeeping — detected language: English.
github-actions commentedon Jul 29, 2026
Issue reopened
The report now contains the information required by the automated check. Thanks for updating it.
[-]Kiro login import misses Windows Kiro CLI token DB path[/-][+][Bug]: Kiro login import misses Windows Kiro CLI token DB path[/+]lidge-jun commentedon Jul 29, 2026
Fixed on
dev— credential discovery now includes the Windows Kiro CLI store, soocx login kiroimports an existingkiro-clisession without theKIROCLI_DB_PATHworkaround.Thanks for the report quality here. The exact path, the
auth_kv/kirocli:social:tokenschema detail, and the env-var workaround together proved the reader and token selector already worked and that only the candidate path list was short — that turned this into a narrow, well-scoped fix.The candidate list is now resolved per platform via a pure
(env, platform, home)resolver, with Windows following%LOCALAPPDATA%→%USERPROFILE%\AppData\Local→ the platform-native home. The fallback deliberately avoids the module'sHOME-first home helper, since Windows shells such as Git Bash export a POSIX-styleHOMEthat would aim it at a non-native path.One thing your report surfaced beyond the bug itself: the install instructions shown when login fails are Unix-only in all 12 places they appear. That mattered less before this fix, because the Windows import could not succeed anyway — now it is the only remaining rough edge on that path. Filed separately as #716.
Verification: full suite 5987 pass / 0 fail, typecheck clean, plus a new suite covering each Windows path-resolution rung by name.
Please reopen if the import still needs the env override on your machine after this lands.
lidge-jun commentedon Jul 29, 2026
Heads-up before this gets pushed: the fix commit currently fails
bun run privacy:scan, which is a required CI gate.I confirmed the scope rather than guessing.
origin/devatd24c5233fpasses the scan cleanly; the failure appears only with14d58ec1dapplied, and it still reproduces with every unrelated working-tree change stashed. So it is this commit, not anything around it.The cause is the allowlist in
scripts/privacy-scan.ts:60:Test fixtures may use
example,test, orxas the home-directory username. The new fixture usesu, which is not on that list, so the/Users/([A-Za-z0-9_-]+)/pattern flags it.Only the two macOS fixture lines are affected — 58 (
home: "/Users/u") and 62 (the expected/Users/u/Library/Application Support/...path). The Windows fixtures are fine:C:\Users\udoes not match the forward-slash pattern the scanner uses, soWIN_HOMEand theLOCALAPPDATA/USERPROFILEcases at lines 16-49 need no change.Renaming
utoxin those two spots is the smallest fix and keeps the fixture's intent (a deliberately short home path). I have not touched the file since it is your working change.Unrelated but worth knowing while you are looking at CI: the Windows
testjob had only ~12 seconds of headroom undertimeout-minutes: 12, which is why recent Windows checks looked randomly red. I filed #717 with the per-job timings and raised the ceiling to 20 minutes oncodex/260730-ci-windows-timeout(commit4359d540b, unpushed).fix(kiro): discover the Windows kiro-cli token DB on login import (#710)
fix(kiro): make native-store resolution platform-correct off macOS (#718
lidge-jun commentedon Jul 30, 2026
Fixed and now fully green on
dev.The discovery fix landed in
c7fe9e808:resolveKiroCliNativeSessionEntriesgained awin32branch resolving%LOCALAPPDATA%\Kiro-Cli\data.sqlite3— the exact path you verified — with%USERPROFILE%\AppData\Localand the injected home as fallback rungs. YourKIROCLI_DB_PATHworkaround is no longer needed;ocx login kiroimports the session directly.Thanks for the report quality, by the way. The exact path, the DB schema keys, and a working env-var workaround meant the reader and token selector never had to be guessed at — only discovery was short.
Follow-up worth knowing about. That commit also split the diagnostic location label per platform (
kiro-cli-data/kiro-cli-linux-data/kiro-cli-windows-data), which turneddevred onubuntu-latestandwindows-latestwhilemacos-lateststayed green — invisible to anyone developing on a Mac. Two defects, tracked and fixed as #718:inspectKiroCliSqliteexpectations still hardcoded the darwin label (fixed in8f499a45f, now derived via akiroCliDbLocation()helper);joinwhile win32 correctly pinnedwin32.join, so on a Windows host they emitted backslashes (also8f499a45f, both branches now pinposix.join);table auth_kv already exists(bfacc3bcf).CI run 30505367421 is green on all six jobs. Closing this as delivered.
fix(kiro): resolve the Windows kiro-cli executable without PATH
fix(kiro): discover the Windows kiro-cli token DB on login import (li…
fix(kiro): make native-store resolution platform-correct off macOS (l…
fix(kiro): resolve the Windows kiro-cli executable without PATH