Repository navigation
[Bug]: T3 Code opens a blank window when the Linux credential store is locked #9239
Description
What happened
After updating the Linux AppImage from stable 0.0.35 to
0.0.36-nightly.20260827.1207,
T3 Code opened a completely black window that could not be resized. The splash
screen sometimes appeared first. No authentication prompt appeared anywhere in
the reporter's Niri session. The black window was the only visible symptom.
This is the first affected build observed. Stable 0.0.35 was not tested with
the credential store locked, so it is not a confirmed working baseline for this
condition.
Unlocking the native credential store made the same AppImage start normally.
An authentication prompt appeared later in an isolated Xvfb/Openbox test.
While the prompt remained open, the T3 window stalled. Dismissing it allowed T3
to show Primary environment request failed during fetch-session-state (HTTP 500). The prompt never appeared during the original failure.
Expected: T3 Code may wait for the credential store to be unlocked, but its
window should remain responsive. It should show the authentication request or
a recoverable error.
Actual: T3 Code opens a black, non-resizable window with no explanation of what
it is waiting for.
Area: apps/desktop
Impact: Blocks work completely
Diagnosis
T3 Code is waiting on the locked credential store during startup. We reproduced
this on the current nightly with three different Linux credential providers.
Unlocking each store made the project picker load. Bypassing encrypted storage
with --password-store=basic also made it load.
The tests identify the failing boundary, but not the exact T3, Clerk, or
Electron call that waits for the store.
Steps to reproduce
- Start a Linux desktop session with its native credential store locked. In
the original case, the credential-store service restarted after login and no
longer had the password supplied by PAM. - Launch the T3 Code AppImage.
- Observe that T3 opens a black, non-resizable window. No authentication prompt
appears. - Unlock the credential store, close T3 Code, and launch the same AppImage.
- Observe that the project picker loads normally.
The same locked-versus-unlocked test ran in three separate, pinned NixOS VMs:
| Credential provider in test VM | Locked | Unlocked |
|---|---|---|
| GNOME Keyring 50.0 | window opens; UI does not load within 5 seconds | project picker loads |
| KeePassXC 2.7.12 | window opens; UI does not load within 5 seconds | project picker loads |
| KDE KWallet 6.29.0 | window opens; UI does not load within 5 seconds | project picker loads |
These provider names describe disposable test VMs, not the reporter's host.
GNOME Keyring and KeePassXC use the freedesktop Secret Service API in these
tests. KWallet uses Chromium's separate KWallet integration.
The five-second cutoff detects the startup stall. It does not claim that every
provider waits forever. One exploratory KeePassXC run recovered after about 25
to 30 seconds.
Version
0.0.39-nightly.20260902.1257,
commit 70cd258d8aac43ea57494527b00bf36de3efa6c0.
AppImage SHA-256:
a8fa9413b6aa7bde3f5ad7c94def29f6aafaaac3f185f7d14f47eef60550e929
Environment
Reporter: Linux x86_64, Niri on Wayland, AppImage, native encrypted credential
store.
Validation: pinned NixOS VMs, Linux 6.18.46, Xvfb/Openbox. The tests use the
extracted, hash-pinned AppImage, so they do not cover Niri/Wayland or the FUSE
mount path.
Evidence
locked: app ready -> safe storage ready -> main window created -> UI probe timed out
unlocked: renderer ready -> "Add project"
basic: renderer ready -> "Add project"
One isolated test also recorded an authentication prompt starting before the
timeout. After that prompt was dismissed, T3 displayed:
Something went wrong.
Primary environment request failed during fetch-session-state (HTTP 500).
PrimaryEnvironmentRequestError
The screenshot shows this post-dismissal error. During the original failure,
the prompt never appeared and the window remained completely black.
Related issues
- #3513 covers the same
post-failure session-state error and its poor recovery. This report adds a
specific trigger, a locked credential store, and the black window that appears
before the error. - #5427,
#2539,
#2880, and
#7689 cover missing or
unavailable secure storage. Here T3 selects an encrypted credential store,
but that store is locked.
Fix applied or workaround
Unlocking the credential store restores startup. Logging out and back in can
unlock it through PAM when that integration is configured.
--password-store=basic avoids the stall but stores credentials without native
encryption. It is useful as a diagnostic, not as a safe default.
Filed by
OpenAI Codex (gpt-5.6-sol) via t3 triage.
Activity
[-]T3 Code opens a blank window when the Linux credential store is locked[/-][+][Bug]: T3 Code opens a blank window when the Linux credential store is locked[/+]selenodot commentedon Sep 2, 2026
Investigating this issue
eliesgalvira commentedon Sep 2, 2026
@selenodot One additional finding may help with the next version of the fix.
0.0.28nightly.20260619.598(20f37f) remains responsive with the credential store locked. The immediately following nightly,0.0.28nightly.20260619.602(3e01c4), freezes. The only intervening change was “Migrate desktop auth to Clerk bridge” (#3092).Instrumentation of the affected build stopped in the Clerk tokencache save path:
storage.setItem()→resolveCipher()→safeStorage.isEncryptionAvailable()Both mainprocess and renderer heartbeats stopped at that call.
Current T3 Code also reaches the same blocking API through the connectioncatalog path, so the general diagnosis in #9246 is sound. The narrower conclusion is that Clerk was the historical caller at the firstbad release boundary, while the connection catalog is another current caller of the same synchronous API.
solomonneas commentedon Sep 5, 2026
Additional occurrence on Ubuntu 24.04.4 LTS, Linux x86_64, using the T3 Code AppImage and the
gnome_libsecretbackend on September 5.The window rendered an empty project sidebar and then showed
Still connecting/T3 Code could not confirm this workspace.Existing projects were inaccessible. Repeated application launches did not recover it. A host reboot restored catalog reads and the project list.The retained
desktop.trace.ndjsonfiles provide this sequence. Times are UTC, and durations are from completed spans:Startup reported
safe storage readywithbackend=gnome_libsecret. The recovered desktop was0.0.39-nightly.20260905.1288. Several nightly builds were used during recovery, so that version is a recovery reference, not a confirmed first affected version.This supports the startup/catalog boundary described here. I did not capture a native stack during the stall or establish whether the credential store was locked, so I cannot independently identify the exact blocking call. The symptom on this host was a rendered but unusable shell rather than a completely black window. I do not have a deterministic reproduction on this host after reboot.
The preservation concern raised on #9246 matters for a follow-up fix: a temporary secure-storage timeout must not turn an unread catalog into an empty catalog that is later persisted over the original. A recovery test should start with a populated encrypted catalog, make secure storage unavailable, then restore it and verify that the saved environments and credentials survive.