[Bug]: Disabling Local environment does not persist; Nightly repeatedly conflicts with background service after restart #26144

Activity

1. juliusmarminge

   added

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   on Oct 27, 2026
2. juliusmarminge commented on Oct 27, 2026

   

   juliusmarminge

   on Oct 27, 2026 – with GitCafe Production

   Member

   More actions

   Tried this on current main (5e9d564) with the Linux desktop app. A separate T3 server owned the T3 home, standing in for the background service.

   • No desktop-settings.json: the desktop shows "This T3 home is unavailable". Matches your step 2. Dismissing it quits without writing the settings file.
   • {"localEnvironmentEnabled": false} written by hand, then the app launched: "This computer is off", no server start. Matches your step 5. Moving or closing the window rewrites the file, and the key stays: {"localEnvironmentEnabled":false,"mainWindowBounds":{…}}.
   • Closed and relaunched with the same file: still off, the key still there.

   On main, the only thing that writes desktop-settings.json is the desktop app. It writes the state it loaded at startup and drops only values equal to the default. So the key disappears only when a desktop process believes the local environment is on. That happens after the Local environment toggle in Settings → Connections, or in a T3 Code desktop process that loaded the file before your edit. To tell which one it was:

   1. The desktop records every settings write in its trace. Could you post the output of this command? It prints only span names, times and the toggle value:

      grep -h '"name":"desktop.settings' ~/.t3/userdata/logs/desktop.trace.ndjson* | python3 -c '
      import sys, json, datetime
      for l in sys.stdin:
          r = json.loads(l)
          print(datetime.datetime.fromtimestamp(int(r["startTimeUnixNano"]) / 1e9), r["name"], r.get("attributes", {}))'

      The interesting lines are a desktop.settings.setLocalEnvironmentEnabled with enabled: true, and the desktop.settings.writeSettings near 2026-10-27 22:27:41. If the trace has already rotated past Oct 24–27, say so.
   2. Between Oct 24 and Oct 27, did any other T3 Code desktop build (stable, or another Nightly copy) start against the default ~/.t3? Did "This computer is off" → Open Environments → the Local environment switch get used in that profile?
   3. The Nightly version at the Oct 27 launch (About T3 Code).

   Attaching the desktop to a same-machine background service, and a recovery action inside the dialog, are separate requests. https://git.cafe/pingdotgg/t3code/issues/22821 tracks the dialog's advice.
3. github-actions

   removed

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   on Oct 28, 2026
4. juliusmarminge commented on Nov 12, 2026

   

   juliusmarminge

   on Nov 12, 2026

   Member

   More actions

   @heykerim Could you run the trace command from the maintainer's Oct 27 comment (grep the desktop.settings spans in ~/.t3/userdata/logs/desktop.trace.ndjson*) and post the lines around 2026-10-27 22:27:41, especially any desktop.settings.setLocalEnvironmentEnabled with enabled: true, and say whether any other T3 Code desktop build or window was running against the default ~/.t3 between Oct 24 and Oct 27?
5. heykerim commented on Nov 13, 2026

   

   heykerim

   on Nov 13, 2026 – with ChatGPT Codex Connector

   Last edited by heykerim

   Author

   More actions

   @juliusmarminge Thanks for investigating and for testing the behavior against current main. Here is a more complete response to your three questions, with the exact observations and the limits of what I can verify.

   1. Requested desktop settings trace (Oct 27, 22:27:41)

   On Nov 13, I inspected the available ~/.t3/userdata/logs/desktop.trace.ndjson* files read-only. The scan parsed JSON spans whose name starts with desktop.settings, converting timestamps to Europe/Bratislava local time and selecting Oct 24–28, 2026.

   Result:

   Matching events: 0; trace files: 11
   

   Therefore I cannot provide the desktop.settings.writeSettings span at 2026-10-27 22:27:41, nor confirm a desktop.settings.setLocalEnvironmentEnabled event with enabled: true. Those events are not in the available traces under that filter. The traces may have rotated, but I haven't independently established that. I don't want to claim that the setting changed spontaneously when we have no record identifying its writer.

   For reference, this was the actual read-only check (showing just timestamps, span names and the enabled attribute rather than full potentially sensitive trace contents):

   import json
   from pathlib import Path
   from datetime import datetime, date
   from zoneinfo import ZoneInfo
   
   files = sorted(Path.home().glob(".t3/userdata/logs/desktop.trace.ndjson*"))
   count = 0
   for path in files:
       with path.open(errors="replace") as f:
           for line in f:
               if '"desktop.settings' not in line:
                   continue
               try:
                   r = json.loads(line)
                   name = r.get("name", "")
                   dt = datetime.fromtimestamp(
                       int(r["startTimeUnixNano"]) / 1e9,
                       ZoneInfo("Europe/Bratislava")
                   )
               except (ValueError, KeyError, TypeError):
                   continue
               if not name.startswith("desktop.settings"):
                   continue
               if not date(2026, 10, 24) <= dt.date() <= date(2026, 10, 28):
                   continue
               attrs = r.get("attributes") or {}
               enabled = attrs.get("enabled", "-") if isinstance(attrs, dict) else "-"
               print(f"{dt:%Y-%m-%d %H:%M:%S} | {name} | enabled={enabled}")
               count += 1
   print(f"Matching events: {count}; trace files: {len(files)}")

   2. Other desktop builds and whether the Local environment switch was used

   I installed T3 Code Beta only after the original Nightly/normal desktop launch had begun failing with "This T3 home is unavailable". I was trying to regain access, not intentionally create two independent local servers. Later, I adopted the separate-home T3 Remote launcher workaround.

   The sequence I can verify from the screenshots and terminal output is:

   • Oct 23: Nightly failed to open because the installed background service was using the default ~/.t3 home. Updated the service from 0.0.46-nightly.20261015.3158 to 0.1.2 stable using npx t3@latest update; the service restarted, but normal desktop launches still failed. Service uninstall/reinstall did not address this ownership conflict.
   • Oct 23: Running open -na "T3 Code (Nightly)" --env "T3CODE_HOME=$HOME/.t3-desktop" opened Nightly successfully with an initially empty project list. In this separate home I disabled Local environment, connected to the existing always-on server at localhost:3773, and could access my original projects and threads again.
   • Oct 24: With Nightly closed, added "localEnvironmentEnabled": false to the default ~/.t3/userdata/desktop-settings.json (backed up beforehand). Normal launch then opened without the ownership dialog and showed "This computer is off", consistent with the local environment being disabled.
   • Oct 27: The ownership dialog recurred after a normal launch. At 22:29 local, I inspected both settings files read-only:

     ~/.t3/userdata/desktop-settings.json
       modified 2026-10-27 22:27:41
       localEnvironmentEnabled: MISSING
     
     ~/.t3-desktop/userdata/desktop-settings.json
       modified 2026-10-23 17:41:31
       localEnvironmentEnabled: False
     

   • Oct 27 onward: A custom AppleScript T3 Remote.app launcher which runs open -na "T3 Code (Nightly)" --env "T3CODE_HOME=$HOME/.t3-desktop" consistently opened Nightly with the original server and projects. Normal Nightly launches had previously continued to hit the ownership dialog.

   On your specific question about another desktop instance using the default ~/.t3: Beta was installed as part of troubleshooting after the first failure, but I cannot reliably reconstruct whether it or another Nightly instance was open against the default home at 22:27:41 on Oct 27. I also have no recorded evidence of deliberately switching Local environment back ON in that default-home profile, but I cannot rule out an accidental toggle or another desktop process loading an older/default settings snapshot. So an older-running or alternate desktop instance rewriting the JSON is still a credible explanation.

   3. Nightly build on Oct 27

   I don't have a screenshot of About T3 Code from that exact launch. The build clearly visible in an earlier Oct 23 Connections screenshot was:

   0.1.3-nightly.20261023.3579
   

   I cannot assert this was still the installed build on Oct 27 after Nightly updates. The background service was verified as 0.1.2 during the Oct 23 recovery; I did not recheck its version at the Oct 27 incident.

   What is established vs. still open

   Established: the background server continued serving the original threads/projects from localhost:3773; the same-machine desktop's default-home launch hit the ownership dialog; separate T3CODE_HOME + Local environment OFF + pairing worked; after a successful default-home recovery, the key was later absent in a newly modified default-home settings file.

   Not established: which process wrote that file on Oct 27, whether a toggle to ON occurred, whether traces have rotated, or a reproducible persistence defect on current main. Your successful reproduction with the key surviving on Linux is useful evidence against assuming a generic write/persistence bug.

   My primary user-facing request remains: please make the supported same-machine desktop + always-on service setup usable without creating a custom macOS launcher, ideally while retaining local editor/Finder integrations. I understand that automatic attachment and error-dialog recovery are distinct improvements and am happy for those to be tracked separately from this settings investigation.

   If the existing traces cannot identify the writer, I'd appreciate guidance on the smallest safe logging/diagnostic setup to capture the responsible desktop process, effective T3CODE_HOME, and toggle state if this happens again, without uploading full logs containing private workspace or account data.
6. juliusmarminge

   added

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   and removed

   needs more infoInitial triage showed no bug. Awaiting more infoInitial triage showed no bug. Awaiting more info

   on Nov 13, 2026
7. juliusmarminge

   closed this as completedin #36168on Nov 13, 2026