fix(server): open-in-editor works when the boot service predates the desktop session - #1919

…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]>

…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

Fork-Domain: upstream-fixes
Fork-Tier: bugfix
Fork-Upstreamable: yes
Co-authored-by: donjor <[email protected]>

…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]>

…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

Fork-Domain: upstream-fixes
Fork-Tier: bugfix
Fork-Upstreamable: yes
Co-authored-by: donjor <[email protected]>

…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]>

…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

Fork-Domain: upstream-fixes
Fork-Tier: bugfix
Fork-Upstreamable: yes
Co-authored-by: donjor <[email protected]>

…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]>

…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

Fork-Domain: upstream-fixes
Fork-Tier: bugfix
Fork-Upstreamable: yes
Co-authored-by: donjor <[email protected]>

…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]>

…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

Fork-Domain: upstream-fixes
Fork-Tier: bugfix
Fork-Upstreamable: yes
Co-authored-by: donjor <[email protected]>

…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]>

…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

Fork-Domain: upstream-fixes
Fork-Tier: bugfix
Fork-Upstreamable: yes
Co-authored-by: donjor <[email protected]>

…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]>

…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

Fork-Domain: upstream-fixes
Fork-Tier: bugfix
Fork-Upstreamable: yes
Co-authored-by: donjor <[email protected]>

…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]>

…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

Fork-Domain: upstream-fixes
Fork-Tier: bugfix
Fork-Upstreamable: yes
Co-authored-by: donjor <[email protected]>

…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]>

…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

Fork-Domain: upstream-fixes
Fork-Tier: bugfix
Fork-Upstreamable: yes
Co-authored-by: donjor <[email protected]>

…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]>

…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

Fork-Domain: upstream-fixes
Fork-Tier: bugfix
Fork-Upstreamable: yes
Co-authored-by: donjor <[email protected]>

…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]>

…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

Fork-Domain: upstream-fixes
Fork-Tier: bugfix
Fork-Upstreamable: yes
Co-authored-by: donjor <[email protected]>

…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]>

…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

…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

…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

…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

…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

…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

…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

…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

…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

…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

…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

…es the desktop session (#1919)

Give the upstream Zed daemon-rejection fixture a graphical session through an additive HostProcess.Environment provider. Preserve every upstream line and its strict version-only spawn assertion, without triggering the separately covered boot-service recovery path.

Fork-Domain: upstream-fixes
Fork-Tier: bugfix
Fork-Upstreamable: yes

…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

…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

…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

…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

…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

…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

…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

…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

…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

…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

…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

…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

…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

…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

…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

…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

…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

…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