Repository navigation
dev is red on ubuntu-latest and windows-latest: kiro-cli diagnostics tests hardcode the macOS location label #718
Description
dev has been failing ubuntu-latest and windows-latest since c7fe9e808 ("fix(kiro): discover the Windows kiro-cli token DB on login import", #710). macos-latest passes, so this is invisible to anyone developing on a Mac. It currently blocks every merge into dev.
Evidence
dev's own push run 30501949889 at e4153e11b fails on both platforms with the same five cases:
(fail) kiro oauth — import-first > inspectKiroCliSqlite reports safe diagnostics without token values
(fail) kiro oauth — import-first > inspectKiroCliSqlite distinguishes schema mismatch from no token
(fail) kiro oauth — import-first > inspectKiroCliSqlite distinguishes token_missing and invalid_json
(fail) kiro oauth — import-first > inspectKiroCliSqlite distinguishes unreadable database path
(fail) kiro oauth — import-first > SQLite import reads device registration and state profile region without leaking diagnostics
Windows additionally fails three cases in tests/kiro-windows-cli-db-path.test.ts.
Root cause
c7fe9e808 gave each platform its own diagnostic location label (src/oauth/kiro-credentials.ts:160-169):
win32 -> "kiro-cli-windows-data"
darwin -> "kiro-cli-data"
linux -> "kiro-cli-linux-data"The test helper follows the platform correctly (tests/kiro-oauth.test.ts:87-91 picks the win32 / darwin / XDG directory), but the assertions still hardcode the macOS label. For example tests/kiro-oauth.test.ts:620 and :636:
expect(result.diagnostics).toContainEqual({ location: "kiro-cli-data", status: "token_found" });
expect(result.diagnostics).toContainEqual({ location: "kiro-cli-data", status: "schema_mismatch" });On Linux the resolver reports kiro-cli-linux-data, so toContainEqual cannot match. Verified the resolver itself is correct on every platform:
darwin [{"location":"kiro-cli-data","path":"/Users/x/Library/Application Support/kiro-cli/data.sqlite3"}]
linux [{"location":"kiro-cli-linux-data","path":"/home/u/.local/share/kiro-cli/data.sqlite3"}]
win32 [{"location":"kiro-cli-windows-data","path":"C:\\Users\\u\\AppData\\Local\\Kiro-Cli\\data.sqlite3"}]
So the shipped behaviour is fine — only the test expectations are platform-blind.
Fix
Derive the expected label the same way the helper derives the directory, rather than hardcoding one platform's value. Something like a kiroCliDbLocation() sibling to kiroCliDbDir() returning kiro-cli-windows-data / kiro-cli-data / kiro-cli-linux-data, then use it in all five assertions.
Worth checking the three kiro-windows-cli-db-path.test.ts failures in the same pass; that file drives the pure resolver with explicit arguments so it should be platform-independent, and its Windows-only failure suggests a separate path-separator or fixture assumption.
Why this is filed rather than fixed
Found while landing #646, whose own required checks cannot go green while dev is red. I stopped short of patching it because #710 landed minutes earlier and I did not want to collide with whoever is still in that code. Happy to take it if no one else is on it — the fix looks small and the diagnosis above is complete.
Activity
github-actions commentedon Jul 30, 2026
Automated translation bookkeeping — detected language: English.
fix(kiro): make native-store resolution platform-correct off macOS (#718
test(kiro): clear the platform store between seeds, not just the macO…
lidge-jun commentedon Jul 30, 2026
Fixed on
devby8f499a45fandbfacc3bcf. CI run 30505367421 atbfacc3bcfis green on all six jobs —ubuntu-latest,windows-latest,macos-latest, and the threenpm-globalvariants.There were two independent defects, not one. The second only became visible after the first was fixed and ubuntu went from 5 failures to 1.
8f499a45f— the diagnosed pair.resolveKiroCliNativeSessionEntriespinnedwin32.joinon the Windows branch but left darwin and linux on the platform-agnosticjoin, so on a Windows host those emitted backslashes (\Users\x\Library\...instead of/Users/x/Library/...). Both now pinposix.join. And the sixinspectKiroCliSqliteexpectations hardcoded the darwin labelkiro-cli-data, which #710 had split per platform; they now derive it through a newkiroCliDbLocation()helper sitting beside the existingkiroCliDbDir().bfacc3bcf— the one the first fix uncovered.inspectKiroCliSqlite distinguishes token_missing and invalid_jsonseeds a database, asserts, then re-seeds for the invalid-JSON branch. Its mid-test cleanup removed only$tmp/Library, the macOS store, so on Linux the.local/share/kiro-clidatabase survived and the second seed hitSQLiteError: table auth_kv already exists. It now removeskiroCliDbDir(), following the platform exactly as the seeding side already did.Both are the same class of bug: the platform being decided by the machine running the code rather than by the argument, which is precisely why macOS CI stayed green throughout.
One correction worth recording about my own guard. My first regression assertion checked the returned path for backslashes. That cannot fail from a POSIX host — there
joinandposix.joinare the same function, so reverting the fix still passed. An ablation caught it. The shipped guard reads which joiner each branch uses instead, and the ablation now behaves correctly: 6 pass / 1 fail withposix.joinreverted, 7 pass with it restored.The shipped resolver behaviour was correct the whole time. Nothing user-facing changed — this was stale test expectations plus one Windows-host path-separator bug.
fix(kiro): make native-store resolution platform-correct off macOS (l…
test(kiro): clear the platform store between seeds, not just the macO…