[Bug]: T3 Code fails to start after upgrade from 0.0.15 to 0.0.17 - backend readiness timeout #1916

Activity

1. codemanat commented on Apr 11, 2026

   

   codemanat

   on Apr 11, 2026

   More actions

   I’m experiencing the same issue with T3Code. This is a fresh installation of the desktop app on windows and it has never been installed on this system before.
   Even though the error message “T3 Code failed to start” appears, the website itself is accessible. However, the error in the app occurs before I’m able to enter the pairing code.

   In an additional test, I noticed that the website only becomes available after the error message appears.

   

   👍React with 👍2Reacted by Max and JanWartenberg
2. betterthanclay commented on Apr 11, 2026

   

   betterthanclay

   on Apr 11, 2026

   More actions

   Same issue for me - I actually had v0.0.16 running last night.. first attempt at booting gave the error, second attempt ran OK. Then upgraded to v0.0.17 this morning, now I can't get either version to boot. Consistently get the timeout error for both versions - I have around 20 project folders open in the app which may contribute. I tried rebooting in case there were any stuck processes etc.

   I can confirm going back to v0.0.15 works - it took quite a while for all the projects / threads to show (which made me sweat a bit!) but it all appears to be working fine for me downgrading.
3. Leonitis616 commented on Apr 11, 2026

   

   Leonitis616

   on Apr 11, 2026

   More actions

   Not sure if this helps, i had the same issue i managed to get claude code to fix it.

   Here's its response for what fixed the issue from the lengthy session i had with it. Hope it helps steer in the right direction:

   Fix: patch the startup timeout

   Close T3 Code first. You'll need Node.js installed.

   Install the asar tool:
   npm install -g @electron/asar

   Back up your asar file (run in PowerShell):
   $p = "$env:LOCALAPPDATA\Programs\t3-code-desktop\resources"
   Copy-Item "$p\app.asar" "$p\app.asar.backup"

   Create a file called patch-t3.mjs with this content:
   import asar from '@electron/asar';
   import { readFileSync, writeFileSync } from 'fs';

   const asarPath = process.env.LOCALAPPDATA.replace(/\/g, '/') +
   '/Programs/t3-code-desktop/resources/app.asar';
   const extractDir = asarPath + '-extracted';

   // Extract
   asar.extractAll(asarPath, extractDir);

   // Patch timeout
   const mainJs = extractDir + '/apps/desktop/dist-electron/main.js';
   const src = readFileSync(mainJs, 'utf8');
   const patched = src.replace(
   'const DEFAULT_TIMEOUT_MS = 1e4',
   'const DEFAULT_TIMEOUT_MS = 6e4'
   );
   if (patched === src) throw new Error('Pattern not found — may differ in your version');
   writeFileSync(mainJs, patched, 'utf8');

   // Repack (must preserve native modules outside asar)
   await asar.createPackageWithOptions(extractDir, asarPath, {
   unpack: '*.{node,dll,exe}',
   unpackDir: 'node_modules/{@anthropic-ai/claude-agent-sdk,@img/sharp-win32-x64,@msgpackr-extract/msgpackr-extract-win32-x64,msgpackr-extract,node-pty}'
   });

   console.log('Done. T3 Code will now wait 60s for backend startup instead of 10s.');

   Run it:
   node patch-t3.mjs

   That's it — launch T3 Code and it should start normally.
4. ZeuxMD commented on Apr 11, 2026

   

   ZeuxMD

   on Apr 11, 2026

   More actions

   Same issue on Omarchy 3.5 after upgrading from v0.0.15 to 0.0.17 through yay.
   It gives the following output /usr/bin/t3code: line 22: /opt/t3code-bin/usr/bin/t3code: No such file or directory
5. rdbtCVS commented on Apr 11, 2026

   

   rdbtCVS

   on Apr 11, 2026

   More actions

   Same issue on Omarchy 3.5 after upgrading from v0.0.15 to 0.0.17 through yay. It gives the following output /usr/bin/t3code: line 22: /opt/t3code-bin/usr/bin/t3code: No such file or directory

   this is a separate issue with the aur repo that was introduced in the latest commit

   👍React with 👍1Reacted by Mohamed Adel
6. arham-saigol commented on Apr 11, 2026

   

   arham-saigol

   on Apr 11, 2026

   More actions

   Same issue, update from v0.0.15 to v0.0.17 fails.
7. Saikrishna1876 commented on Apr 12, 2026

   

   Saikrishna1876

   on Apr 12, 2026

   Contributor

   More actions

   I had the same error, so I uninstalled the app, and reinstalled from the same dmg, and it works fine now.
8. kevinkliimask commented on Apr 12, 2026

   

   kevinkliimask

   on Apr 12, 2026

   More actions

   Had this error pop up when I shut down my mac and then when opening it, T3 Code tried to relaunch and gave me exactly the same error. But after closing the popup, the app managed to launch fine
9. ZeuxMD commented on Apr 12, 2026

   

   ZeuxMD

   on Apr 12, 2026

   More actions

   @rdbtCVS you are right, I fixed it by manually editing the entry in /usr/bin/t3code to point to /opt/t3code-bin
10. rowalth commented on Apr 13, 2026

    

    rowalth

    on Apr 13, 2026

    Contributor

    More actions

    Root cause analysis with log evidence

    I traced this through desktop and server logs on macOS (v0.0.17, x64). The issue is straightforward: the backend takes longer to start than the hardcoded 10-second timeout allows.

    Timing from actual logs — last successful start after v0.0.17 auto-update:

    Phase	Duration
    Node.js startup + SQLite init	8.0s
    Migrations (4 actual)	0.2s
    Post-migration init → Listening	0.9s
    Total	9.2s

    That's 0.8s under the 10s limit. Every cold start after that exceeded 10s (10.5–12s) and failed.

    The trigger on my machine: toggling "Network Access" in Settings, which requests an app relaunch. From that point on, every cold start timed out. But the toggle itself isn't the bug — it just happened to cause the first restart after a long-running session.

    Relevant log lines (~/.t3/userdata/logs/desktop-main.log):

    [14:12:08.377Z] bootstrap backend start requested
    [14:12:17.559Z] bootstrap backend ready          ← 9.18s, last success
    ...
    [20:41:35.413Z] desktop relaunch requested reason=serverExposureMode=network-accessible
    ...
    [20:41:48.593Z] bootstrap backend start requested
    [20:41:59.461Z] fatal startup error stage=bootstrap message=Timed out waiting for backend readiness
    

    The backend does eventually start — server-child.log shows Listening on http://... about 1–2 seconds after the desktop gives up:

    [22:06:48.961Z] desktop timeout    ← gave up
    [22:06:49.316Z] Listening on http://127.0.0.1:3773  ← backend ready 0.35s later
    

    macOS workaround (simpler than asar extract/repack)

    The existing workaround from @Leonitis616 works for Windows. On macOS, the code-signed app bundle blocks writes in /Applications, and extracting/repacking the asar changes the file size, which complicates re-signing.

    Simpler approach — binary patch in place (same byte length, no repack):

    Since 1e4 and 6e4 are the same byte length, you can patch the asar directly without extracting:

    # 1. Copy app out of /Applications (code signing blocks in-place edits)
    mkdir -p ~/Applications
    cp -R "/Applications/T3 Code (Alpha).app" ~/Applications/"T3 Code (Alpha).app"
    
    # 2. Strip signature and quarantine
    codesign --remove-signature ~/Applications/"T3 Code (Alpha).app"
    xattr -rd com.apple.quarantine ~/Applications/"T3 Code (Alpha).app"
    
    # 3. Binary patch: 10s → 60s (same byte length, no offset change)
    python3 -c "
    asar = '$HOME/Applications/T3 Code (Alpha).app/Contents/Resources/app.asar'
    data = open(asar, 'rb').read()
    old = b'const DEFAULT_TIMEOUT_MS = 1e4'
    new = b'const DEFAULT_TIMEOUT_MS = 6e4'
    assert data.count(old) == 1, 'pattern not found — version may differ'
    open(asar, 'wb').write(data.replace(old, new, 1))
    print('Patched: 10s -> 60s')
    "
    
    # 4. Re-sign ad-hoc and move back
    codesign --force --deep --sign - ~/Applications/"T3 Code (Alpha).app"
    sudo rm -rf "/Applications/T3 Code (Alpha).app"
    mv ~/Applications/"T3 Code (Alpha).app" /Applications/"T3 Code (Alpha).app"

    All data (conversations, projects, settings) lives in ~/.t3/userdata/, not in the app bundle, so this is safe. The patch needs to be reapplied after auto-updates.

    Suggested code fix

    The timeout is hardcoded in apps/desktop/src/backendReadiness.ts:9:

    const DEFAULT_TIMEOUT_MS = 10_000;

    The WaitForHttpReadyOptions interface already supports a timeoutMs override, but main.ts never passes one. Either increasing the default to 30s or making it configurable via environment variable would fix this for everyone.
11. rowalth

    added a commit that references this issue on Apr 13, 2026

    fix(desktop): increase backend readiness timeout from 10s to 30s

    ...

    This issue will close once commit e273835 is merged into the 'main' branch.

    e273835
12. juliusmarminge

    closed this as completedin #1979on Apr 13, 2026
13. solrevdev commented on Apr 13, 2026

    

    solrevdev

    on Apr 13, 2026

    More actions

    Can confirm this on two Mac Mini M1 machines running macOS Tahoe.

    Installed via Homebrew cask, upgraded from v0.0.15 to v0.0.17.

    Got the same bootstrap timeout error on first launch after the upgrade.

    Worked fine on subsequent launches.

    Thanks for the fix 🙏🏼️