Repository navigation
fix(server): boot-service editor launches read the session display over D-Bus, as upstream does - #1920
Merged
Conversation
🧩 Effect Service Conventions
|
donjor
force-pushed
the
t3/open-in-editor-busctl
branch
from
October 29, 2026 01:50
3b3d562 to
16ea723
Compare
🩺 Aftercare
|
| Head | Result | Time | Check |
|---|---|---|---|
dad5d8a |
🟡 1 open · 1 fixed · 1 held | 4 min | run |
16ea723 |
🟡 2 open · 2 new | 7 min | run |
…er D-Bus, as upstream does Adopt the reader from upstream `pingdotgg#25228`: `busctl --user --json=short` returns raw values where `systemctl show-environment` shell-quotes ones with spaces, and only editor launches get the display, so browsers stay on the server's own environment. The fork keeps one extra hook: file-manager detection also reads the session display. Drop this commit once upstream ships `pingdotgg#25228`; keep the `readBrowserLaunchEnv` hook if upstream has no equivalent. Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
donjor
force-pushed
the
t3/open-in-editor-busctl
branch
from
October 29, 2026 02:08
16ea723 to
dad5d8a
Compare
Author
A1: drop the timeout only reaches the same |
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Oct 29, 2026
…er D-Bus, as upstream does (#1920) ## Problem The boot-service display fix from #1919 has two flaws upstream's version avoids. - **Quoting:** spaced values come back as `$'…'` - **Browsers:** they also got the session display A quoted `XAUTHORITY` path with a space breaks the editor's X auth. Upstream keeps browsers off it so the pairing page never opens on another session's screen. Upstream has the same fix open as `pingdotgg#25228` (maintainer branch, green). ## Change `externalLauncher.ts` carries the `pingdotgg#25228` reader line for line: - **Source:** `busctl --json=short`, raw values - Only `DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY` - **Scope:** editor launches only - **Fallback:** error or timeout keeps server env One fork-only hook keeps the file-manager entry available on a boot service; `pingdotgg#25228` leaves detection unchanged. ```diff +// Fork: the boot service's file-manager entry also needs the session display. const readBrowserLaunchEnv = Effect.gen(function* () { const env = yield* BrowserLaunchEnvConfig.pipe(Effect.orElseSucceed(() => ({}))); - return { ...env, ...(yield* readSessionDisplayEnv(env)) }; + return { ...env, ...(yield* readGraphicalSessionEnv()) }; }); ``` **Retirement:** once a tagged upstream release ships `pingdotgg#25228`, the rebase drops this commit and keeps only that hook. ## Scope and approval Follow-up to #1919 in the same function and `upstream-fixes` domain. ## Verification - [x] Fork test: raw `XAUTHORITY` with a space - [x] Fork test: file manager discovered and launched - [x] Fork test: browser launch gets only `PATH` - [x] Fork test: bad JSON or no `busctl` falls back - [x] Fork test fails on the old code - [x] Fork test fails without the fork hook - [x] 21 launcher tests pass, display set or unset - [x] Real launcher, display unset, stub `code` - Stub saw `DISPLAY=:1`, `WAYLAND_DISPLAY=wayland-1` - [x] Diffed against the `pingdotgg#25228` head: same code - [x] `vp run typecheck` (server) → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not run: full reboot cycle on this branch Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes Co-authored-by: donjor <[email protected]>
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Oct 29, 2026
…er D-Bus, as upstream does (#1920) ## Problem The boot-service display fix from #1919 has two flaws upstream's version avoids. - **Quoting:** spaced values come back as `$'…'` - **Browsers:** they also got the session display A quoted `XAUTHORITY` path with a space breaks the editor's X auth. Upstream keeps browsers off it so the pairing page never opens on another session's screen. Upstream has the same fix open as `pingdotgg#25228` (maintainer branch, green). ## Change `externalLauncher.ts` carries the `pingdotgg#25228` reader line for line: - **Source:** `busctl --json=short`, raw values - Only `DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY` - **Scope:** editor launches only - **Fallback:** error or timeout keeps server env One fork-only hook keeps the file-manager entry available on a boot service; `pingdotgg#25228` leaves detection unchanged. ```diff +// Fork: the boot service's file-manager entry also needs the session display. const readBrowserLaunchEnv = Effect.gen(function* () { const env = yield* BrowserLaunchEnvConfig.pipe(Effect.orElseSucceed(() => ({}))); - return { ...env, ...(yield* readSessionDisplayEnv(env)) }; + return { ...env, ...(yield* readGraphicalSessionEnv()) }; }); ``` **Retirement:** once a tagged upstream release ships `pingdotgg#25228`, the rebase drops this commit and keeps only that hook. ## Scope and approval Follow-up to #1919 in the same function and `upstream-fixes` domain. ## Verification - [x] Fork test: raw `XAUTHORITY` with a space - [x] Fork test: file manager discovered and launched - [x] Fork test: browser launch gets only `PATH` - [x] Fork test: bad JSON or no `busctl` falls back - [x] Fork test fails on the old code - [x] Fork test fails without the fork hook - [x] 21 launcher tests pass, display set or unset - [x] Real launcher, display unset, stub `code` - Stub saw `DISPLAY=:1`, `WAYLAND_DISPLAY=wayland-1` - [x] Diffed against the `pingdotgg#25228` head: same code - [x] `vp run typecheck` (server) → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not run: full reboot cycle on this branch Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes Co-authored-by: donjor <[email protected]>
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Oct 29, 2026
…er D-Bus, as upstream does (#1920) ## Problem The boot-service display fix from #1919 has two flaws upstream's version avoids. - **Quoting:** spaced values come back as `$'…'` - **Browsers:** they also got the session display A quoted `XAUTHORITY` path with a space breaks the editor's X auth. Upstream keeps browsers off it so the pairing page never opens on another session's screen. Upstream has the same fix open as `pingdotgg#25228` (maintainer branch, green). ## Change `externalLauncher.ts` carries the `pingdotgg#25228` reader line for line: - **Source:** `busctl --json=short`, raw values - Only `DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY` - **Scope:** editor launches only - **Fallback:** error or timeout keeps server env One fork-only hook keeps the file-manager entry available on a boot service; `pingdotgg#25228` leaves detection unchanged. ```diff +// Fork: the boot service's file-manager entry also needs the session display. const readBrowserLaunchEnv = Effect.gen(function* () { const env = yield* BrowserLaunchEnvConfig.pipe(Effect.orElseSucceed(() => ({}))); - return { ...env, ...(yield* readSessionDisplayEnv(env)) }; + return { ...env, ...(yield* readGraphicalSessionEnv()) }; }); ``` **Retirement:** once a tagged upstream release ships `pingdotgg#25228`, the rebase drops this commit and keeps only that hook. ## Scope and approval Follow-up to #1919 in the same function and `upstream-fixes` domain. ## Verification - [x] Fork test: raw `XAUTHORITY` with a space - [x] Fork test: file manager discovered and launched - [x] Fork test: browser launch gets only `PATH` - [x] Fork test: bad JSON or no `busctl` falls back - [x] Fork test fails on the old code - [x] Fork test fails without the fork hook - [x] 21 launcher tests pass, display set or unset - [x] Real launcher, display unset, stub `code` - Stub saw `DISPLAY=:1`, `WAYLAND_DISPLAY=wayland-1` - [x] Diffed against the `pingdotgg#25228` head: same code - [x] `vp run typecheck` (server) → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not run: full reboot cycle on this branch Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes Co-authored-by: donjor <[email protected]>
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Oct 30, 2026
…er D-Bus, as upstream does (#1920) ## Problem The boot-service display fix from #1919 has two flaws upstream's version avoids. - **Quoting:** spaced values come back as `$'…'` - **Browsers:** they also got the session display A quoted `XAUTHORITY` path with a space breaks the editor's X auth. Upstream keeps browsers off it so the pairing page never opens on another session's screen. Upstream has the same fix open as `pingdotgg#25228` (maintainer branch, green). ## Change `externalLauncher.ts` carries the `pingdotgg#25228` reader line for line: - **Source:** `busctl --json=short`, raw values - Only `DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY` - **Scope:** editor launches only - **Fallback:** error or timeout keeps server env One fork-only hook keeps the file-manager entry available on a boot service; `pingdotgg#25228` leaves detection unchanged. ```diff +// Fork: the boot service's file-manager entry also needs the session display. const readBrowserLaunchEnv = Effect.gen(function* () { const env = yield* BrowserLaunchEnvConfig.pipe(Effect.orElseSucceed(() => ({}))); - return { ...env, ...(yield* readSessionDisplayEnv(env)) }; + return { ...env, ...(yield* readGraphicalSessionEnv()) }; }); ``` **Retirement:** once a tagged upstream release ships `pingdotgg#25228`, the rebase drops this commit and keeps only that hook. ## Scope and approval Follow-up to #1919 in the same function and `upstream-fixes` domain. ## Verification - [x] Fork test: raw `XAUTHORITY` with a space - [x] Fork test: file manager discovered and launched - [x] Fork test: browser launch gets only `PATH` - [x] Fork test: bad JSON or no `busctl` falls back - [x] Fork test fails on the old code - [x] Fork test fails without the fork hook - [x] 21 launcher tests pass, display set or unset - [x] Real launcher, display unset, stub `code` - Stub saw `DISPLAY=:1`, `WAYLAND_DISPLAY=wayland-1` - [x] Diffed against the `pingdotgg#25228` head: same code - [x] `vp run typecheck` (server) → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not run: full reboot cycle on this branch Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes Co-authored-by: donjor <[email protected]>
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Oct 30, 2026
…er D-Bus, as upstream does (#1920) ## Problem The boot-service display fix from #1919 has two flaws upstream's version avoids. - **Quoting:** spaced values come back as `$'…'` - **Browsers:** they also got the session display A quoted `XAUTHORITY` path with a space breaks the editor's X auth. Upstream keeps browsers off it so the pairing page never opens on another session's screen. Upstream has the same fix open as `pingdotgg#25228` (maintainer branch, green). ## Change `externalLauncher.ts` carries the `pingdotgg#25228` reader line for line: - **Source:** `busctl --json=short`, raw values - Only `DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY` - **Scope:** editor launches only - **Fallback:** error or timeout keeps server env One fork-only hook keeps the file-manager entry available on a boot service; `pingdotgg#25228` leaves detection unchanged. ```diff +// Fork: the boot service's file-manager entry also needs the session display. const readBrowserLaunchEnv = Effect.gen(function* () { const env = yield* BrowserLaunchEnvConfig.pipe(Effect.orElseSucceed(() => ({}))); - return { ...env, ...(yield* readSessionDisplayEnv(env)) }; + return { ...env, ...(yield* readGraphicalSessionEnv()) }; }); ``` **Retirement:** once a tagged upstream release ships `pingdotgg#25228`, the rebase drops this commit and keeps only that hook. ## Scope and approval Follow-up to #1919 in the same function and `upstream-fixes` domain. ## Verification - [x] Fork test: raw `XAUTHORITY` with a space - [x] Fork test: file manager discovered and launched - [x] Fork test: browser launch gets only `PATH` - [x] Fork test: bad JSON or no `busctl` falls back - [x] Fork test fails on the old code - [x] Fork test fails without the fork hook - [x] 21 launcher tests pass, display set or unset - [x] Real launcher, display unset, stub `code` - Stub saw `DISPLAY=:1`, `WAYLAND_DISPLAY=wayland-1` - [x] Diffed against the `pingdotgg#25228` head: same code - [x] `vp run typecheck` (server) → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not run: full reboot cycle on this branch Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes Co-authored-by: donjor <[email protected]>
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Oct 30, 2026
…er D-Bus, as upstream does (#1920) ## Problem The boot-service display fix from #1919 has two flaws upstream's version avoids. - **Quoting:** spaced values come back as `$'…'` - **Browsers:** they also got the session display A quoted `XAUTHORITY` path with a space breaks the editor's X auth. Upstream keeps browsers off it so the pairing page never opens on another session's screen. Upstream has the same fix open as `pingdotgg#25228` (maintainer branch, green). ## Change `externalLauncher.ts` carries the `pingdotgg#25228` reader line for line: - **Source:** `busctl --json=short`, raw values - Only `DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY` - **Scope:** editor launches only - **Fallback:** error or timeout keeps server env One fork-only hook keeps the file-manager entry available on a boot service; `pingdotgg#25228` leaves detection unchanged. ```diff +// Fork: the boot service's file-manager entry also needs the session display. const readBrowserLaunchEnv = Effect.gen(function* () { const env = yield* BrowserLaunchEnvConfig.pipe(Effect.orElseSucceed(() => ({}))); - return { ...env, ...(yield* readSessionDisplayEnv(env)) }; + return { ...env, ...(yield* readGraphicalSessionEnv()) }; }); ``` **Retirement:** once a tagged upstream release ships `pingdotgg#25228`, the rebase drops this commit and keeps only that hook. ## Scope and approval Follow-up to #1919 in the same function and `upstream-fixes` domain. ## Verification - [x] Fork test: raw `XAUTHORITY` with a space - [x] Fork test: file manager discovered and launched - [x] Fork test: browser launch gets only `PATH` - [x] Fork test: bad JSON or no `busctl` falls back - [x] Fork test fails on the old code - [x] Fork test fails without the fork hook - [x] 21 launcher tests pass, display set or unset - [x] Real launcher, display unset, stub `code` - Stub saw `DISPLAY=:1`, `WAYLAND_DISPLAY=wayland-1` - [x] Diffed against the `pingdotgg#25228` head: same code - [x] `vp run typecheck` (server) → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not run: full reboot cycle on this branch Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes Co-authored-by: donjor <[email protected]>
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Oct 31, 2026
…er D-Bus, as upstream does (#1920) ## Problem The boot-service display fix from #1919 has two flaws upstream's version avoids. - **Quoting:** spaced values come back as `$'…'` - **Browsers:** they also got the session display A quoted `XAUTHORITY` path with a space breaks the editor's X auth. Upstream keeps browsers off it so the pairing page never opens on another session's screen. Upstream has the same fix open as `pingdotgg#25228` (maintainer branch, green). ## Change `externalLauncher.ts` carries the `pingdotgg#25228` reader line for line: - **Source:** `busctl --json=short`, raw values - Only `DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY` - **Scope:** editor launches only - **Fallback:** error or timeout keeps server env One fork-only hook keeps the file-manager entry available on a boot service; `pingdotgg#25228` leaves detection unchanged. ```diff +// Fork: the boot service's file-manager entry also needs the session display. const readBrowserLaunchEnv = Effect.gen(function* () { const env = yield* BrowserLaunchEnvConfig.pipe(Effect.orElseSucceed(() => ({}))); - return { ...env, ...(yield* readSessionDisplayEnv(env)) }; + return { ...env, ...(yield* readGraphicalSessionEnv()) }; }); ``` **Retirement:** once a tagged upstream release ships `pingdotgg#25228`, the rebase drops this commit and keeps only that hook. ## Scope and approval Follow-up to #1919 in the same function and `upstream-fixes` domain. ## Verification - [x] Fork test: raw `XAUTHORITY` with a space - [x] Fork test: file manager discovered and launched - [x] Fork test: browser launch gets only `PATH` - [x] Fork test: bad JSON or no `busctl` falls back - [x] Fork test fails on the old code - [x] Fork test fails without the fork hook - [x] 21 launcher tests pass, display set or unset - [x] Real launcher, display unset, stub `code` - Stub saw `DISPLAY=:1`, `WAYLAND_DISPLAY=wayland-1` - [x] Diffed against the `pingdotgg#25228` head: same code - [x] `vp run typecheck` (server) → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not run: full reboot cycle on this branch Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes Co-authored-by: donjor <[email protected]>
donjor
added a commit
that referenced
this pull request
Nov 6, 2026
…er D-Bus, as upstream does (#1920) ## Problem The boot-service display fix from #1919 has two flaws upstream's version avoids. - **Quoting:** spaced values come back as `$'…'` - **Browsers:** they also got the session display A quoted `XAUTHORITY` path with a space breaks the editor's X auth. Upstream keeps browsers off it so the pairing page never opens on another session's screen. Upstream has the same fix open as `pingdotgg#25228` (maintainer branch, green). ## Change `externalLauncher.ts` carries the `pingdotgg#25228` reader line for line: - **Source:** `busctl --json=short`, raw values - Only `DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY` - **Scope:** editor launches only - **Fallback:** error or timeout keeps server env One fork-only hook keeps the file-manager entry available on a boot service; `pingdotgg#25228` leaves detection unchanged. ```diff +// Fork: the boot service's file-manager entry also needs the session display. const readBrowserLaunchEnv = Effect.gen(function* () { const env = yield* BrowserLaunchEnvConfig.pipe(Effect.orElseSucceed(() => ({}))); - return { ...env, ...(yield* readSessionDisplayEnv(env)) }; + return { ...env, ...(yield* readGraphicalSessionEnv()) }; }); ``` **Retirement:** once a tagged upstream release ships `pingdotgg#25228`, the rebase drops this commit and keeps only that hook. ## Scope and approval Follow-up to #1919 in the same function and `upstream-fixes` domain. ## Verification - [x] Fork test: raw `XAUTHORITY` with a space - [x] Fork test: file manager discovered and launched - [x] Fork test: browser launch gets only `PATH` - [x] Fork test: bad JSON or no `busctl` falls back - [x] Fork test fails on the old code - [x] Fork test fails without the fork hook - [x] 21 launcher tests pass, display set or unset - [x] Real launcher, display unset, stub `code` - Stub saw `DISPLAY=:1`, `WAYLAND_DISPLAY=wayland-1` - [x] Diffed against the `pingdotgg#25228` head: same code - [x] `vp run typecheck` (server) → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not run: full reboot cycle on this branch Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes Co-authored-by: donjor <[email protected]>
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 6, 2026
…er D-Bus, as upstream does (#1920) ## Problem The boot-service display fix from #1919 has two flaws upstream's version avoids. - **Quoting:** spaced values come back as `$'…'` - **Browsers:** they also got the session display A quoted `XAUTHORITY` path with a space breaks the editor's X auth. Upstream keeps browsers off it so the pairing page never opens on another session's screen. Upstream has the same fix open as `pingdotgg#25228` (maintainer branch, green). ## Change `externalLauncher.ts` carries the `pingdotgg#25228` reader line for line: - **Source:** `busctl --json=short`, raw values - Only `DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY` - **Scope:** editor launches only - **Fallback:** error or timeout keeps server env One fork-only hook keeps the file-manager entry available on a boot service; `pingdotgg#25228` leaves detection unchanged. ```diff +// Fork: the boot service's file-manager entry also needs the session display. const readBrowserLaunchEnv = Effect.gen(function* () { const env = yield* BrowserLaunchEnvConfig.pipe(Effect.orElseSucceed(() => ({}))); - return { ...env, ...(yield* readSessionDisplayEnv(env)) }; + return { ...env, ...(yield* readGraphicalSessionEnv()) }; }); ``` **Retirement:** once a tagged upstream release ships `pingdotgg#25228`, the rebase drops this commit and keeps only that hook. ## Scope and approval Follow-up to #1919 in the same function and `upstream-fixes` domain. ## Verification - [x] Fork test: raw `XAUTHORITY` with a space - [x] Fork test: file manager discovered and launched - [x] Fork test: browser launch gets only `PATH` - [x] Fork test: bad JSON or no `busctl` falls back - [x] Fork test fails on the old code - [x] Fork test fails without the fork hook - [x] 21 launcher tests pass, display set or unset - [x] Real launcher, display unset, stub `code` - Stub saw `DISPLAY=:1`, `WAYLAND_DISPLAY=wayland-1` - [x] Diffed against the `pingdotgg#25228` head: same code - [x] `vp run typecheck` (server) → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not run: full reboot cycle on this branch Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes Co-authored-by: donjor <[email protected]>
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 6, 2026
…er D-Bus, as upstream does (#1920) ## Problem The boot-service display fix from #1919 has two flaws upstream's version avoids. - **Quoting:** spaced values come back as `$'…'` - **Browsers:** they also got the session display A quoted `XAUTHORITY` path with a space breaks the editor's X auth. Upstream keeps browsers off it so the pairing page never opens on another session's screen. Upstream has the same fix open as `pingdotgg#25228` (maintainer branch, green). ## Change `externalLauncher.ts` carries the `pingdotgg#25228` reader line for line: - **Source:** `busctl --json=short`, raw values - Only `DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY` - **Scope:** editor launches only - **Fallback:** error or timeout keeps server env One fork-only hook keeps the file-manager entry available on a boot service; `pingdotgg#25228` leaves detection unchanged. ```diff +// Fork: the boot service's file-manager entry also needs the session display. const readBrowserLaunchEnv = Effect.gen(function* () { const env = yield* BrowserLaunchEnvConfig.pipe(Effect.orElseSucceed(() => ({}))); - return { ...env, ...(yield* readSessionDisplayEnv(env)) }; + return { ...env, ...(yield* readGraphicalSessionEnv()) }; }); ``` **Retirement:** once a tagged upstream release ships `pingdotgg#25228`, the rebase drops this commit and keeps only that hook. ## Scope and approval Follow-up to #1919 in the same function and `upstream-fixes` domain. ## Verification - [x] Fork test: raw `XAUTHORITY` with a space - [x] Fork test: file manager discovered and launched - [x] Fork test: browser launch gets only `PATH` - [x] Fork test: bad JSON or no `busctl` falls back - [x] Fork test fails on the old code - [x] Fork test fails without the fork hook - [x] 21 launcher tests pass, display set or unset - [x] Real launcher, display unset, stub `code` - Stub saw `DISPLAY=:1`, `WAYLAND_DISPLAY=wayland-1` - [x] Diffed against the `pingdotgg#25228` head: same code - [x] `vp run typecheck` (server) → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not run: full reboot cycle on this branch Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes Co-authored-by: donjor <[email protected]>
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 6, 2026
…er D-Bus, as upstream does (#1920) ## Problem The boot-service display fix from #1919 has two flaws upstream's version avoids. - **Quoting:** spaced values come back as `$'…'` - **Browsers:** they also got the session display A quoted `XAUTHORITY` path with a space breaks the editor's X auth. Upstream keeps browsers off it so the pairing page never opens on another session's screen. Upstream has the same fix open as `pingdotgg#25228` (maintainer branch, green). ## Change `externalLauncher.ts` carries the `pingdotgg#25228` reader line for line: - **Source:** `busctl --json=short`, raw values - Only `DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY` - **Scope:** editor launches only - **Fallback:** error or timeout keeps server env One fork-only hook keeps the file-manager entry available on a boot service; `pingdotgg#25228` leaves detection unchanged. ```diff +// Fork: the boot service's file-manager entry also needs the session display. const readBrowserLaunchEnv = Effect.gen(function* () { const env = yield* BrowserLaunchEnvConfig.pipe(Effect.orElseSucceed(() => ({}))); - return { ...env, ...(yield* readSessionDisplayEnv(env)) }; + return { ...env, ...(yield* readGraphicalSessionEnv()) }; }); ``` **Retirement:** once a tagged upstream release ships `pingdotgg#25228`, the rebase drops this commit and keeps only that hook. ## Scope and approval Follow-up to #1919 in the same function and `upstream-fixes` domain. ## Verification - [x] Fork test: raw `XAUTHORITY` with a space - [x] Fork test: file manager discovered and launched - [x] Fork test: browser launch gets only `PATH` - [x] Fork test: bad JSON or no `busctl` falls back - [x] Fork test fails on the old code - [x] Fork test fails without the fork hook - [x] 21 launcher tests pass, display set or unset - [x] Real launcher, display unset, stub `code` - Stub saw `DISPLAY=:1`, `WAYLAND_DISPLAY=wayland-1` - [x] Diffed against the `pingdotgg#25228` head: same code - [x] `vp run typecheck` (server) → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not run: full reboot cycle on this branch Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes Co-authored-by: donjor <[email protected]>
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 6, 2026
…er D-Bus, as upstream does (#1920) ## Problem The boot-service display fix from #1919 has two flaws upstream's version avoids. - **Quoting:** spaced values come back as `$'…'` - **Browsers:** they also got the session display A quoted `XAUTHORITY` path with a space breaks the editor's X auth. Upstream keeps browsers off it so the pairing page never opens on another session's screen. Upstream has the same fix open as `pingdotgg#25228` (maintainer branch, green). ## Change `externalLauncher.ts` carries the `pingdotgg#25228` reader line for line: - **Source:** `busctl --json=short`, raw values - Only `DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY` - **Scope:** editor launches only - **Fallback:** error or timeout keeps server env One fork-only hook keeps the file-manager entry available on a boot service; `pingdotgg#25228` leaves detection unchanged. ```diff +// Fork: the boot service's file-manager entry also needs the session display. const readBrowserLaunchEnv = Effect.gen(function* () { const env = yield* BrowserLaunchEnvConfig.pipe(Effect.orElseSucceed(() => ({}))); - return { ...env, ...(yield* readSessionDisplayEnv(env)) }; + return { ...env, ...(yield* readGraphicalSessionEnv()) }; }); ``` **Retirement:** once a tagged upstream release ships `pingdotgg#25228`, the rebase drops this commit and keeps only that hook. ## Scope and approval Follow-up to #1919 in the same function and `upstream-fixes` domain. ## Verification - [x] Fork test: raw `XAUTHORITY` with a space - [x] Fork test: file manager discovered and launched - [x] Fork test: browser launch gets only `PATH` - [x] Fork test: bad JSON or no `busctl` falls back - [x] Fork test fails on the old code - [x] Fork test fails without the fork hook - [x] 21 launcher tests pass, display set or unset - [x] Real launcher, display unset, stub `code` - Stub saw `DISPLAY=:1`, `WAYLAND_DISPLAY=wayland-1` - [x] Diffed against the `pingdotgg#25228` head: same code - [x] `vp run typecheck` (server) → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not run: full reboot cycle on this branch Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes Co-authored-by: donjor <[email protected]>
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 6, 2026
…er D-Bus, as upstream does (#1920) ## Problem The boot-service display fix from #1919 has two flaws upstream's version avoids. - **Quoting:** spaced values come back as `$'…'` - **Browsers:** they also got the session display A quoted `XAUTHORITY` path with a space breaks the editor's X auth. Upstream keeps browsers off it so the pairing page never opens on another session's screen. Upstream has the same fix open as `pingdotgg#25228` (maintainer branch, green). ## Change `externalLauncher.ts` carries the `pingdotgg#25228` reader line for line: - **Source:** `busctl --json=short`, raw values - Only `DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY` - **Scope:** editor launches only - **Fallback:** error or timeout keeps server env One fork-only hook keeps the file-manager entry available on a boot service; `pingdotgg#25228` leaves detection unchanged. ```diff +// Fork: the boot service's file-manager entry also needs the session display. const readBrowserLaunchEnv = Effect.gen(function* () { const env = yield* BrowserLaunchEnvConfig.pipe(Effect.orElseSucceed(() => ({}))); - return { ...env, ...(yield* readSessionDisplayEnv(env)) }; + return { ...env, ...(yield* readGraphicalSessionEnv()) }; }); ``` **Retirement:** once a tagged upstream release ships `pingdotgg#25228`, the rebase drops this commit and keeps only that hook. ## Scope and approval Follow-up to #1919 in the same function and `upstream-fixes` domain. ## Verification - [x] Fork test: raw `XAUTHORITY` with a space - [x] Fork test: file manager discovered and launched - [x] Fork test: browser launch gets only `PATH` - [x] Fork test: bad JSON or no `busctl` falls back - [x] Fork test fails on the old code - [x] Fork test fails without the fork hook - [x] 21 launcher tests pass, display set or unset - [x] Real launcher, display unset, stub `code` - Stub saw `DISPLAY=:1`, `WAYLAND_DISPLAY=wayland-1` - [x] Diffed against the `pingdotgg#25228` head: same code - [x] `vp run typecheck` (server) → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not run: full reboot cycle on this branch Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes Co-authored-by: donjor <[email protected]>
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 6, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 7, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 7, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 7, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 8, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
donjor
pushed a commit
that referenced
this pull request
Nov 9, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 9, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 9, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 9, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 9, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 10, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 10, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 10, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 10, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 10, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 11, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 11, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 11, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 11, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 11, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 11, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 12, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 12, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 12, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 12, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 13, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 13, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 13, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 13, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 14, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 14, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 14, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 14, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 15, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
rsi-software-agent Bot
pushed a commit
that referenced
this pull request
Nov 15, 2026
…desktop session (#1919) ## Problem On Linux, "Open in VS Code" and the file manager silently do nothing when the server runs as the `t3 service` systemd user unit. That unit starts at boot or login, before the compositor imports `DISPLAY`/`WAYLAND_DISPLAY` into the user manager, so the service's environment never has a display. The launcher spawns `code` with that environment, Electron exits with `Missing X server or $DISPLAY`, and with stderr ignored the RPC still reports success. Reproduced on ugrindtime: the service (`t3 __service-launcher`) started 10:31:55, Hyprland started 10:32:24, and `t3 serve` had no display variables while `systemctl --user show-environment` had both. `systemctl --user restart t3code.service` fixed it until the next boot. ## Change `externalLauncher.ts` reads the display variables (`DISPLAY`, `WAYLAND_DISPLAY`, `XAUTHORITY`, `XDG_CURRENT_DESKTOP`, `XDG_SESSION_TYPE`) from `systemctl --user show-environment` when it needs them: - Only on Linux, outside WSL, and only when the process has neither `DISPLAY` nor `WAYLAND_DISPLAY` - Read at launch time, so a session that starts after the service still works without a restart - Fills both the availability checks (file manager, browser) and the spawned editor's environment - `systemctl` missing, failing, or slow (2 s timeout) falls back to the current behavior Processes that already have a display, such as the desktop app's bundled server, never run `systemctl`. ## Scope and approval This is a small fix for an obvious bug in an existing capability: the open-in-editor feature is broken for every Linux desktop user whose server runs as the boot service. The change touches only the external launcher. `externalLauncher.ts` and `bootService.ts` are identical to `upstream/main`, so this is an `upstream-fixes` commit. ## Verification - [x] `externalLauncher.fork.test.ts`: a service env without a display launches `code` with `DISPLAY`/`WAYLAND_DISPLAY` from `systemctl`. It fails without the fix (`expected { PATH } to deeply equal { PATH, DISPLAY, WAYLAND_DISPLAY }`) and passes with it. - [x] Existing `externalLauncher.test.ts` (20 tests) still passes - [x] Runtime, real `systemctl`, `env -i` with no display, `resolveAvailableEditors()`: - Before: `vscode` - After: `vscode,file-manager` - [x] `vp run check:changed` → exit 0 - [x] `vp run fork:ci` → exit 0 - [ ] Not yet checked: clicking the button against a boot-started service running this build. That needs a release on ugrindtime. Claude Opus 5.5 in T3 Code (Claude Code harness). ## Fork trailers Squashes: - 1cdc996 fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) (#1920) - 125d6fe fixup! fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - c7c936d fix(server): open-in-editor works when the boot service predates the desktop session (#1919) (#1919) - 4dec9d1 fix(server): boot-service editor launches read the session display over D-Bus, as upstream does (#1920) (#1920) Fork-Domain: upstream-fixes Fork-Tier: bugfix Fork-Upstreamable: yes
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The boot-service display fix from #1919 has two flaws upstream's version avoids.
$'…'A quoted
XAUTHORITYpath with a space breaks the editor's X auth.Upstream keeps browsers off it so the pairing page never opens on another session's screen.
Upstream has the same fix open as
pingdotgg/t3code#25228(maintainer branch, green).Change
externalLauncher.tscarries the#25228reader line for line:busctl --json=short, raw valuesDISPLAY,WAYLAND_DISPLAY,XAUTHORITYOne fork-only hook keeps the file-manager entry available on a boot service;
#25228leaves detection unchanged.Retirement: once a tagged upstream release ships
#25228, the rebase drops this commit and keeps only that hook.Scope and approval
Follow-up to #1919 in the same function and
upstream-fixesdomain.Verification
XAUTHORITYwith a spacePATHbusctlfalls backcodeDISPLAY=:1,WAYLAND_DISPLAY=wayland-1#25228head: same codevp run typecheck(server) → exit 0vp run fork:ci→ exit 0Claude Opus 5.5 in T3 Code (Claude Code harness).
Fork trailers
Fork-Domain: upstream-fixes
Fork-Tier: bugfix
Fork-Upstreamable: yes