[Bug]: Orphaned safeStorage key makes connection-catalog.json permanently undecryptable, blocking all target listing on Windows#8341

Confirmed the same failure on Windows with T3 Code Alpha 0.0.42 on 2026-09-25.

After an apparent app crash, the sidebar showed no threads. Local diagnosis found:

• state.sqlite passed PRAGMA quick_check; the saved threads and messages were still present.
• The local environment discovery HTTP endpoint responded with 200.
• DesktopConnectionCatalogStore.get repeatedly failed with DesktopConnectionCatalogStoreProtectionError (decrypt-catalog), caused by ElectronSafeStorageDecryptError, then Error while decrypting the ciphertext provided to safeStorage.decryptString.
• After a consistent SQLite backup, closing the desktop app, and renaming only connection-catalog.json aside, restart logs showed successful catalog reads. Thread/message counts were unchanged. Visual sidebar recovery has not been independently verified.

The initial crash and reason decryption stopped working remain unconfirmed. In this case the Electron Local State file predates the catalog, so we cannot establish the profile-recreation trigger described above from timestamps alone.

Current main (e5a46d6c5d00b89afba5274a94d42428c8d79763) still propagates this failure. A focused recovery patch is now prepared and validated locally: preserve the encrypted catalog under a unique backup filename before returning an empty catalog, allowing local discovery to proceed. Preservation failures should remain errors. This addresses the overwrite/data-loss concern on the closed #4454 rather than simply swallowing the error. No plaintext credential fallback is needed.

Validation of the local two-file patch:

• All 10 DesktopConnectionCatalogStore tests pass, including concurrent recovery, byte-for-byte preservation, a subsequent encrypted save, and refusal to recover if the backup rename fails.
• The two new regression cases fail against unmodified main; the recovery case reproduces the same decrypt-catalog error chain.
• Desktop TypeScript check, targeted lint, formatting, and git diff --check pass.
• Catalog get/set/clear operations share a semaphore so recovery cannot rename a concurrent replacement save within the store.

Scope is the decrypt-catalog failure only. Malformed documents, filesystem errors, and legacy migration failures retain their existing error behavior. This has not been validated in a newly packaged desktop binary, and no PR has been opened yet.

Another trigger, from V1 to V2 nightly 0.0.46-nightly.20261003.2610 on Windows 11. Upgrading reproduces this every time when the install has both %APPDATA%\t3code and %APPDATA%\T3 Code (Alpha).

I decrypted each catalog copy offline against each profile's Local State key, unwrapping them with DPAPI and AES-GCM:

• The V1 catalog written by 0.0.44 decrypts only with the key in %APPDATA%\t3code\Local State.
• T3 Code (Alpha)\Local State dates from March and holds a different key.
• The V2 migration in DesktopUserData.ts copies T3 Code (Alpha)\Local State into t3code-v2 because the Alpha profile exists. V2 then cannot decrypt the V1 catalog, and the local environment never connects. The settings page shows "Local environment is not ready yet", and no websocket is ever opened to port 3773.

V1 resolveUserDataPath at v0.0.44 also prefers T3 Code (Alpha) when it exists, yet V1 encrypted with the t3code key. That fits the startup-ordering problem in #14265, where safeStorage loads its key before the profile path is switched. So the V2 migration copies the key V1 should have used, not the one it did use.

Workaround: quit the app, rename ~/.t3/userdata/connection-catalog.json, and relaunch. Threads came back immediately. Saved relay connections re-pair. Suggested fix: when migrating, pick the source Local State whose key actually decrypts the existing catalog, or fall back to an empty catalog as proposed in #13656.

@juliusmarminge

Investigated and posted by Claude Opus 5.5 on high effort.

I hit this on Windows after upgrading to 0.0.46-nightly.20261003.2610 on October 3. An earlier nightly upgrade that day worked; immediately after the next update, all projects disappeared and no environments were connected.

We traced this instance to the V1 → V2 Electron profile migration:

• The installed resolveUserDataPath code creates %APPDATA%\t3code-v2\Local State, preferring %APPDATA%\T3 Code (Alpha)\Local State when it exists, and falling back to %APPDATA%\t3code\Local State.
• Both older profiles existed on my machine.
• The saved connection-catalog.json decrypted successfully with the key from t3code.
• Decryption failed with the keys from both T3 Code (Alpha) and t3code-v2.

Desktop logs repeatedly reported:

The local server remained healthy on 127.0.0.1:3773, reporting protocol 2 and the same nightly version. Both databases retained the project records, and the V2 database contained 68 thread records and 1,602 messages.

Recovery was to back up the encrypted catalog, decrypt it using the working t3code key, and re-encrypt it using the current V2 key. After restarting, logs confirmed successful catalog loading, local WebSocket authentication, shell snapshot loading, and project metadata loading. No project database changes or connection resets were needed.

This appears to be a specific migration trigger for this issue: an existing stale Alpha profile takes precedence over the profile whose key actually encrypted the shared connection catalog. Could the migration validate which source key decrypts the catalog before selecting it?

Filed the Orchestrator V2 nightly variant of this separately as #15001, since it has a distinct cause: on win32, resolveUserDataPath seeds t3code-v2\Local State from T3 Code (Alpha) whenever that folder exists, even when the catalog was encrypted with the t3code key. Decrypting connection-catalog.json manually with each profile's os_crypt.encrypted_key only succeeds with the t3code key, which matches what @AngeloTadeucci and @gstamp described above.

Additional reproduction: recurring restart failure even when the persisted Windows key decrypts the catalog

Area: apps/desktop
Impact: Blocks work completely after affected startups.
Observed build: 0.0.46-nightly.20261012.3035 (also observed earlier in 0.0.46-nightly.20261012.3021).
Environment: Windows 11 Pro, x64, OS build 10.0.26200.

This appears related to this issue and #15001, but the important difference from an orphaned-key case is that the failing catalog can still be decrypted with the existing profile key.

Reproduction observed on this machine

1. Start the Windows nightly and use the local environment and T3 Connect.
2. Quit/reopen the desktop app, or restart Windows and reopen it.
3. On affected startups, the app shows a blank white screen or does not register/list environments. The failure has recurred after several temporary recoveries. It is intermittent: some successive cold launches work, but later restarts fail again.
4. The desktop log reports DesktopConnectionCatalogStoreProtectionError during decrypt-catalog.

The failure also occurs with an explicit launch argument:

The main process was verified to run under the ordinary Windows user account. An elevated process is not required to reproduce it.

Independent decryption result

While the desktop app is in the failed state:

• Read os_crypt.encrypted_key from %APPDATA%\t3code-v2\Local State.
• Remove the DPAPI prefix and unwrap it with Windows ProtectedData.Unprotect using CurrentUser.
• Decode the catalog's encryptedCatalog value. It has the v10 prefix.
• Decrypt its AES-GCM payload using the unwrapped key, the 12-byte nonce, and the trailing 16-byte authentication tag.

Both the Windows key unwrap and authenticated catalog decryption succeed, and the plaintext parses as the expected connection catalog JSON. No tokens, key material, or catalog plaintext are included in this report.

The persisted Local State file predates these failures and its modification time did not change across the observed restarts. On this machine the inspected roaming T3 profile directory was t3code-v2; a stale Alpha profile was not found. This does not establish an orphaned key or the specific migration trigger in #15001.

Sanitized logs and checks

This separates the failure from provider login, backend availability, and a renderer crash. The exact cause of the discrepancy between independent decryption and Electron safeStorage.decryptString remains unconfirmed; an in-process key/profile initialization or caching problem is a hypothesis, not a verified root cause.

Temporary recovery and recurrence

With the app closed, preserve/rename only connection-catalog.json, then reopen the app. Catalog reads return successfully, the normal UI and local environment appear, and existing chats remain available. T3 Connect may need sign-in and remote route discovery again. The chat database and provider credentials were not reset, and the installed application code was not patched.

This recovery was visually verified, but the failure returned after later restarts. Merely forcing --user-data-dir was not a durable fix.

Latest nightly source check, 2026-10-13

The latest Windows nightly found was v0.0.46-nightly.20261013.3066. Comparing release tags 3035...3066 showed no changes to DesktopConnectionCatalogStore.ts, DesktopUserData.ts, or DesktopClerk.ts. In the 3066 tag, DesktopConnectionCatalogStore.get still calls safeStorage.decryptString and propagates a decryption failure as DesktopConnectionCatalogStoreProtectionError, blocking catalog/bootstrap loading.

This is a source review of 3066, not a claim that 3066 was installed or runtime-tested here.

Please investigate why Electron rejects ciphertext that the persisted profile key successfully decrypts, and ensure a connection-catalog failure cannot block the local environment/UI bootstrap. Any recovery should preserve the encrypted original and avoid silently overwriting saved routes.

I ran into this issue after upgrading from 0.0.45 to 0.1.0 My previously added environment is missing and can not be readded.

The Workaround is fine tho.

New trigger on stable 0.1.0 (Windows): a temporary DPAPI master-key failure made Electron replace the Local State key

Reported symptom (user's words, paraphrased): after updating to 0.1.0, T3 Connect connections and the local environment stopped working. Local agents can't be used, other machines running T3 Code can't be controlled, and the mobile app doesn't work either. The user is signed in to T3 Connect, but nothing shows under Connections. Reinstalling didn't help.

The symptom matches this issue and #15001, but the trigger is different from #15001's Alpha-profile seeding. The #15001 workarounds (copying or re-encrypting with the t3code key) and the recovery in #20152 can't help here, because no key left on the machine can open the catalog.

Timeline (local time; from desktop.trace.ndjson and Windows event logs)

Diagnosis

• On Windows, Chromium's os_crypt generates and stores a new random key when DPAPI can't unwrap the existing encrypted_key. T3 Code happened to launch during the ~25-minute DPAPI outage, so its key was replaced and the original wrapped key was lost.
• The outage was temporary; the old master key wasn't lost. Three other Electron apps on the same account still have Local State keys wrapped with the old master key, and those keys unwrap fine today. Only T3's key references the new master key.
• Every Local State key under %APPDATA% was tested read-only and in memory (DPAPI unwrap, then AES-256-GCM on the catalog's v10 blob). None of them, including t3code and t3code-v2, authenticates the catalog. No T3 Code (Alpha) profile exists on this machine.
• Reinstalling doesn't help, because %USERPROFILE%\.t3\userdata and %APPDATA%\t3code* survive it.
• Why DPAPI failed is unconfirmed. It coincided with the first sign-in after a Windows Update restart, made over Remote Desktop. The user reports that Remote Desktop sign-ins with the same Microsoft account password worked normally before. That part is outside T3. The T3-relevant point is that any temporary DPAPI failure at app launch permanently orphans the catalog and blocks the local environment.

Fix applied

1. Quit the app.
2. Renamed %USERPROFILE%\.t3\userdata\connection-catalog.json to a .bak (kept, not deleted).
3. Relaunched.

The desktop and server traces after relaunch show:

• desktop.connectionCatalogStore.get succeeded.
• The backend was ready in about 5 s.
• EnvironmentRpc requests were served and environment.orchestration.shellSnapshot succeeded.
• environment.cloud.activateManagedTunnel and environment.cloud.health succeeded.

The user then confirmed in the app that it works again. Saved connections in the old catalog are lost, because they can't be recovered without the original key.

Relevance to fixes

Only suggestion 1 in the original report covers this trigger: degrade an undecryptable catalog to empty, keep a backup and re-key on the next write. The recovery patch described above by @widingmarcus-cyber would also cover it. #20152's key recovery doesn't apply, because the original key no longer exists anywhere. Storing a plaintext key fingerprint with the catalog would also let the UI report "catalog was encrypted with a key this machine no longer has" instead of a transient-looking connection error.

Environment: Windows 11 Pro 10.0.26300 x64. T3 Code 0.1.0 stable (latest channel), upgraded from V1 to V2 through the in-app updater.

No keys, tokens, catalog contents, hostnames or account identifiers are included.

🤖 Generated with Claude Opus 5.5 via Claude Code

Confirmed the same decrypt-catalog failure on macOS after updating T3 Code Nightly. The desktop app appeared to have lost all projects and conversation history.

Environment

• macOS, Darwin 27.0.0, arm64.
• Desktop app and bundled local server: 0.1.1-nightly.20261020.3399.
• Triage CLI: 0.1.1-nightly.20261020.3399, launched with npx t3@nightly triage.

Evidence

• The existing statev2.sqlite still contained 10 projects, 466 legacy threads, and thousands of messages. V2 projection tables were also populated.
• Desktop logs showed desktop.connectionCatalogStore.get and desktop.ipc.connectionCatalog.get failing with:

• The renderer reported ConnectionTransientError: Could not load the local connection catalog.
• Restarting the desktop app alone did not restore the projects.

Recovery verified

1. Quit the desktop app completely.
2. Renamed only ~/.t3/userdata/connection-catalog.json to a backup, preserving the original encrypted file.
3. Reopened the desktop app.

The next catalog reads succeeded, the local server responded, and shell snapshot loading succeeded. The user confirmed that the projects and conversation history returned. The database was not modified by the triage agent. Saved remote connections may need to be registered again.

The reason decryption stopped working is not established. This confirms the same catalog-decryption failure and empty-app symptom on macOS; it does not establish the Windows key/profile lifecycle cause described in the original report.

Prepared via T3 triage with GPT-6 in Codex.

Also reproduces on macOS (arm64) with desktop Nightly 0.1.1-nightly.20261020.3399

After two consecutive nightly updates, the desktop app showed no threads or providers, and Settings → Providers said "Connect an environment to set up its providers." The data on disk was intact.

• connection-catalog.json was written successfully by the first update's build.
• On the next launch, and on every launch after that, the read failed with DesktopConnectionCatalogStoreProtectionError … decrypt-catalog, caused by ElectronSafeStorageDecryptError: Error while decrypting the ciphertext provided to safeStorage.decryptString.
• Restarting the app and rebooting the Mac didn't help.
• Workaround, confirmed working: quit the app, rename connection-catalog.json to .bak, relaunch. The catalog read then returns Success and threads and providers are back.

Diagnosed by Claude (claude-sonnet-5-5) in a Claude Code session, using the T3 triage playbook.

Triage: this is a desktop catalog-recovery bug, not a reported exploitable vulnerability. Existing work: #13656 is closed; #20152 is open and recovers catalogs when an accessible Windows profile key still matches. It does not cover a catalog whose original key is gone. Reviewed the issue and all nine comments; scanned all 943 open issues and 1,385 open PRs. No additional PR opened. No real Electron/Windows reproduction was attempted here. Escalating for maintainer review because changing encrypted credential-catalog recovery is outside the automated triage authorization; leaving this issue open.

Reproduced the catalog-read failure on main at 3b95e7831b: built and launched the real Electron desktop on Linux/Xvfb with isolated state and a working gnome-libsecret backend, then invoked the renderer connection-catalog IPC against undecryptable ciphertext. It rejects with DesktopConnectionCatalogStoreProtectionError during decrypt-catalog, caused by ElectronSafeStorageDecryptError. The native Windows profile-reset trigger is not verified here. No exact duplicate found in the open-issue scan; the accessible-profile-key recovery in #20152 does not cover a permanently lost key.

Additional Windows reproduction: intermittent restart failures through 0.1.3 Nightly

Prepared by Codex at the affected user's explicit request. This comment includes only application behavior and sanitized technical findings; no account/device names, personal paths, network addresses, pairing codes, credentials, screenshots, or raw diagnostic bundles are attached.

Observed versions: 0.0.42; 0.0.46-nightly.20261011.2994; 0.1.1-nightly.20261017.3238; and 0.1.3-nightly.20261023.3579. Platform: Windows x64, packaged desktop app; Nightly track for the later versions.

Observed steps and impact

1. Use the desktop app with a local environment and an existing paired remote environment.
2. Close/reopen via the pinned taskbar shortcut, or restart after an in-app update.
3. On some launches, the sidebar shows “No projects yet”, New thread is disabled, and the local environment is unavailable.
4. Trying to add an environment fails while listing targets because the encrypted local connection catalog cannot be loaded.

This is intermittent, not a deterministic minimal repro. A successful launch or two did not prevent recurrence on later restarts. Saved data remained present; actual project/thread deletion was not established.

Sanitized errors

a) Recurring failure:

b) A launch around the update to 0.1.3-nightly.20261023.3579 also failed with:

Multiple desktop instances were present around that update. A causal relationship between those instances, the bearer-session error, and catalog decryption has not been established.

Evidence and unsuccessful workarounds

• In an earlier failing instance, the existing encrypted catalog successfully decrypted offline under the same Windows account using the stored Electron Local State key. No decrypted contents or keys are being shared.
• Stored protected-key fingerprints in the current/legacy profile locations matched; later checks found those keys unchanged.
• Explicitly passing the existing profile through --user-data-dir in Desktop, Start menu and pinned taskbar shortcuts allowed successful launches, but later failures recurred. A failing process was confirmed to already have that argument.
• Seeding an alternate branded startup profile with the same existing protected key also did not prevent a later recurrence.
• Catalog reset/rename had previously unblocked startup temporarily, but does not explain or prevent recurrence and requires re-adding saved remote entries.

Limited local boot-ordering experiment On the installed 0.1.3-nightly.20261023.3579 build, a local boot-entry patch selected the existing Windows Electron userData profile synchronously before loading compileCache.cjs/main.cjs, and registered a ready handler to initialize safeStorage availability. The original application archive was backed up; the catalog was left unchanged.

After closing the failed instances and launching the patched build, the traces reported Success for:

• desktop.startup
• desktop.connectionCatalogStore.get
• desktop.localEnvironmentAuth.getBearerToken

Existing remote projects and threads returned without resetting the catalog or re-pairing, and the user confirmed that the app worked again.

Limits: only one fresh launch was verified after this boot patch; the planned repeated-restart tests were not completed. This supports investigating startup ordering, but does not establish the exact intermittent trigger or prove a permanent fix. An application update can overwrite the local patch.

Expected: select the intended Windows encryption profile before anything initializes secure storage; reliably restore saved environments after restarts/updates; show an actionable recovery error rather than an apparently empty app; preserve potentially recoverable encrypted data.

Related: #15001 and the earlier startup-ordering proposal #14265. This adds recurrence despite matching stored keys and explicit profile arguments, plus the observed 0.1.3 bootstrap failure and limited boot-ordering experiment.

Additional evidence from T3 Code 0.1.2 (packaged commit 044f07257c96) on Windows: the same executable can work when launched from the MSIX-packaged Codex app and fail when launched from Explorer/the pinned taskbar icon.

This appears to be another trigger for the shared-catalog/protection-profile mismatch tracked here, rather than evidence of the Alpha migration trigger in #15001.

Observed behavior

On the affected installation:

1. Launch T3 as a child of a process running under the Codex desktop app. Existing chats and connections load.
2. Close T3 completely.
3. Launch the same installed executable by double-clicking it in Explorer. The sidebar shows “No projects yet”, and the connection catalog fails to decrypt. The user also observed the empty UI when opening the pinned taskbar icon.
4. The underlying Windows and WSL chat databases still contain the existing data.

This is a reproduction on an existing installation, not a clean-install recipe for creating the initial divergence.

Profile and catalog evidence

The executable was the same:

%LOCALAPPDATA%\Programs\t3code\T3 Code (Beta).exe

The two physical Electron profile locations were:

• Normal Windows profile: %APPDATA%\t3code-v2\Local State
• Codex package-private profile: %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Roaming\t3code-v2\Local State

The catalog remained shared at:

%USERPROFILE%\.t3\userdata\connection-catalog.json

A diagnostic helper launched from Codex used GetFinalPathNameByHandleW to resolve the nominal roaming-profile path to the package-private location above. The catalog and executable did not receive that redirection. This measurement was made in the helper's inherited process context; we did not capture a file-open trace inside T3's main process.

Both physical Local State files contained an os_crypt.encrypted_key field, and their protected values differed. That alone is not proof of different underlying AES keys, because protected wrappers can differ. No key or credential values were decrypted or printed during this comparison.

The installed desktop bundle uses Electron safeStorage.encryptString / safeStorage.decryptString for the shared catalog. The failing Explorer launch recorded:

The path in that excerpt is redacted.

Recovery and verification

After closing T3 and backing up both Electron profiles and both environments' data, a narrowly scoped recovery reconciled only the protected os_crypt.encrypted_key field in the normal Local State with the working profile. Other JSON properties were preserved. Profile-specific compatibility checks included confirming that the normal profile's Cookies databases did not contain encrypted cookie values.

Afterward:

• Launching from Explorer loaded the Windows and WSL histories.
• The user then closed T3 and launched it from the pinned taskbar icon. The resulting window was inspected and showed both environments' histories.
• Both catalog reads in that taskbar launch returned Success; a subsequent launch also returned Success for both reads.
• Database integrity checks passed. Compared thread fields, all message rows, and the checked settings files matched the backups.

This is a description of a machine-specific recovery, not general advice to copy encryption keys between profiles. Other encrypted state can depend on a profile's key, and this recovery does not implement a product fix preventing future divergence.

Windows and WSL were both enabled, with “WSL only” disabled. Their databases remained separate; WSL was not a second Electron profile.

Expected behavior and limits

Launching the same installation through different Windows launchers should not silently turn existing data into an apparently empty setup. If a protection-context mismatch prevents reading the catalog, T3 should identify the failure and provide a safe recovery path that preserves recoverable connection data.

The observed path redirection, launcher-dependent decryption result, and successful targeted recovery support a protection-profile mismatch. The initial creation of the divergent profiles and reproduction on a clean machine remain unverified.

No raw logs, recordings, databases, personal directory names, chat contents, or protected values are attached.

Prepared with assistance from Codex, including GPT-6.1 Sol drafting. The investigation was conducted in an existing Codex session, not by launching a new t3 triage session.