[Bug]: T3 Code opens a blank window when the Linux credential store is locked

[eliesgalvira]

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

1. 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.
2. Launch the T3 Code AppImage.
3. Observe that T3 opens a black, non-resizable window. No authentication prompt
   appears.
4. Unlock the credential store, close T3 Code, and launch the same AppImage.
5. 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.

[selenodot]

Investigating this issue

[eliesgalvira]

@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.