[Bug]: Linux AppImage crashes with ICU SIGTRAP when enabling Network access#16629

Before submitting

I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.

The matching proposed fix is #15681, which is open and unmerged. This issue records the observed failure and independent reproduction for maintainer triage; it does not request approval of a particular implementation. Related reports and their differences are listed below.

Area

apps/desktop

Steps to reproduce

On Fedora 44 x86-64 / KDE / Wayland, launch the official T3 Code 0.0.45 x86_64 AppImage with --no-sandbox. Start with Network access disabled (serverExposureMode: "local-only").
Open Settings → Connections and enable Network access; allow the requested desktop restart.
The existing process exits, but the replacement does not return to a usable window. Inspect coredumpctl for the replacement process: it has SIGTRAP.

An empty isolated profile reproduces the failure, so no project, chat history, active agent turn, or long-running session is required. To start a separate test instance from a writable directory:

bash

1	# Set this to the downloaded 0.0.45 x86_64 AppImage.
2	appimage_path=/absolute/path/T3-Code-0.0.45-x86_64.AppImage
3	trial_dir=$(mktemp -d "$PWD/t3-repro.XXXXXX")
4	# Choose an unused backend port.
5	trial_port=43773
6
7	env -u APPIMAGE -u APPDIR -u ELECTRON_RUN_AS_NODE -u NODE_OPTIONS \
8	T3CODE_HOME="$trial_dir/t3-home" \
9	XDG_CONFIG_HOME="$trial_dir/config" \
10	XDG_DATA_HOME="$trial_dir/data" \
11	XDG_CACHE_HOME="$trial_dir/cache" \
12	T3CODE_DISABLE_AUTO_UPDATE=true \
13	T3CODE_PORT="$trial_port" \
14	"$appimage_path" --no-sandbox > "$trial_dir/startup.log" 2>&1
15
16	# After triggering the restart in that test window:
17	coredumpctl list --since "5 minutes ago"

How the controlled reproduction was operated: the unmodified packaged AppImage was launched with the separate paths above and a dynamically selected unused port. A loopback Node inspector invoked the main window's webContents.executeJavaScript with:

1	window.desktopBridge.setServerExposureMode("network-accessible")

This is the renderer bridge for the setting's desktop:set-server-exposure-mode IPC method. The test first confirmed the initial mode was local-only and the main window had finished loading. The automated reproduction directly exercised that setting action; manual clicks through its confirmation dialog were not recorded.

Expected behavior

The setting is saved, the desktop restarts successfully, and the replacement opens a usable window with Network access enabled.

Actual behavior

The setting is saved, the old process exits normally, and the replacement crashes during Chromium/ICU startup with SIGTRAP / int3. Both the original crash core and the reproduced crash core contain:

text

1	ERROR:base/i18n/icu_util.cc:237
2	Invalid file descriptor to ICU data received.

The evidence strongly isolates the failure to the packaged AppImage restart/resource lifetime:

Check	Observation
Original user incident	Enabling Network access requested a relaunch; replacement PID 30875 crashed with SIGTRAP about two seconds later.
Unmodified AppImage, fresh isolated profile	The same setting action requested a relaunch. The old mount `/tmp/.mount_T3-CodDGCtZU` was absent afterward; replacement PID 35459 crashed with the same ICU error and the same first five native stack offsets.
Minimal missing-ICU test	The shipped `t3code` executable and `libffmpeg.so`, placed in a scratch directory without `icudtl.dat`, failed under GDB with `--no-sandbox --version`: same ICU error, SIGTRAP, and crash offset `0x5736e5e`, before T3's interface loaded.
Persistent extracted-directory control	The same AppImage was extracted to a persistent scratch directory, then its `AppRun` was launched with another empty profile. The same setting action restarted successfully. Replacement PID 37277 had a loaded `t3code://app/#/welcome` window and returned `mode: "network-accessible"` with an advertised endpoint.

Relevant shipped source: DesktopLifecycle.ts at commit 6c8fed35dded, lines 165–169 calls:

1	electronApp.relaunch({
2	execPath: process.execPath,
3	args: process.argv.slice(1),
4	});
5	electronApp.exit(0);

The bundled main.cjs was checked against that source. In the AppImage reproduction, process.execPath pointed to /tmp/.mount_T3-CodDGCtZU/t3code, while APPIMAGE pointed to the durable outer AppImage. The temporary mount disappeared after the old process exited.

Interpretation and limits: relaunching inside the outgoing AppImage mount is consistent with loss of icudtl.dat and the matching startup crash. The successful persistent-directory control and minimal missing-ICU test support that diagnosis. The precise native ordering of unmount, exec, and ICU file lookup was not captured with strace, and the original unsymbolized frames were not mapped to native function names. This report does not establish that simply changing the execPath passed to Electron's native relauncher is a sufficient fix; #15681 also addresses inherited descriptors and no_new_privs.

Impact

Major degradation or frequent failure

The settings restart terminates the desktop instead of returning a usable replacement. The original setting change affected the running desktop session; controlled reproductions used empty profiles. Whether in-progress provider turns recover after this failure was not tested.

Version or commit

Official T3-Code-0.0.45-x86_64.AppImage, stable release.
Package commit: 6c8fed35dded.
Bundled Electron: 44.4.2.
AppImage SHA-256: ab7b0a86d1ea657ccc162b60b772c61f70bc7c8b9e259b46939d53bb38faa02a.
The repository's latest stable release was still v0.0.45 when checked on 7 October 2026. No nightly build was tested in this investigation.

Environment

Fedora Linux 44 (KDE Plasma Desktop Edition), x86-64; kernel 7.2.4-200.fc44.x86_64; KDE / native Wayland; manual AppImage installation launched with --no-sandbox.

No particular provider or model is needed for the reproduction. The isolated-profile startup performed its normal provider discovery, but no user prompt or agent turn was started by the reproduction.

Logs or stack traces

Original incident, 7 October 2026, CEST (UTC+02:00); relevant lines only:

text

1	01:10:13.418 INFO: desktop relaunch requested
2	channel: desktop:set-server-exposure-mode
3	component: desktop-lifecycle
4	reason: serverExposureMode=network-accessible
5
6	01:10:15 replacement PID 30875
7	Signal: 5 (TRAP)
8	Command Line: /t3code --no-sandbox
9	kernel: trap int3

The crash occurred at 0x5736e5e relative to the executable. The independently reproduced replacement crash at 01:27:53 CEST, PID 35459, matches the first five original stack offsets:

Frame	Original PID 30875	Reproduced PID 35459
0	`0x5736e5e`	`0x5736e5e`
1	`0x598ba11`	`0x598ba11`
2	`0x4fd8688`	`0x4fd8688`
3	`0x4fd7fba`	`0x4fd7fba`
4	`0x4fd7dd7`	`0x4fd7dd7`

Minimal missing-ICU GDB run:

text

1	ERROR:base/i18n/icu_util.cc:237] Invalid file descriptor to ICU data received.
2	Program received signal SIGTRAP, Trace/breakpoint trap.
3	CRASH_OFFSET 0x5736e5e

Shutdown also produced desktop:get-local-environment-enabled / ipcRenderer.sendSync() listener warnings. The same warning appeared in the successful extracted-directory control, so it does not by itself explain the native crash. No out-of-memory message was found in the original crash window.

Screenshots, recordings, or supporting files

All relevant text evidence is included above. No screenshot or recording was captured. Raw core dumps, complete process environments, usernames, home-directory paths, private host addresses, and full provider logs are deliberately excluded from this public report.

The original AppImage was read and extracted, not patched. Test processes were closed. A separate initial inspector-setup attempt caused a SIGBUS during forced test cleanup; that setup artifact is excluded from the matching setting-change reproduction and stack comparison above.

Workaround

Verified: run the same extracted AppImage files from a persistent directory; the setting restart succeeded in the isolated control. This was a diagnostic control, not a change to the reporter's installed application.

Manually reopening the outer AppImage after the failed automatic restart is a plausible recovery path, but was not verified against the reporter's existing profile. No source fix was applied or tested.

Related reports and proposed fixes

#15681 — exact failure class: open proposed fix for Linux AppImage settings restarts and ICU SIGTRAP. This issue adds independent evidence on the current stable release, including a matching native stack and a successful extracted-directory control.
#4918 and #4698 — earlier repair attempts: both closed without merging; they describe restarting inside the outgoing FUSE mount and launching the durable outer AppImage instead.
#15387 — overlapping Linux relaunch work: addresses Electron's no_new_privs behavior. Its reported .deb update failure differs from this settings-triggered ICU crash.
#14259 — related, different trigger: the main process disappears without a documented settings restart, followed by mount loss and child SIGBUS crashes. Here the relaunch reason is logged and the replacement main process has a matching ICU SIGTRAP.

Investigated and drafted with Codex desktop at the reporter's request. Maintainer triage is requested for the observed failure; no particular implementation or PR approval is assumed.

CChris-Peeters8d ago

Follow-up: affected relaunch implementation remains in current source

While investigating another user's report of AppImage self-restart failing, I checked the release source for v0.1.1-nightly.20261019.3360 (1451e7cb23034d29774338608368a15d8845df36) and current main (5307c233b1f0ae72b8894dd39d94019aaf9e7cb8). Both still use this production relaunch path:

1	yield* electronApp.relaunch({
2	execPath: process.execPath,
3	args: process.argv.slice(1),
4	});
5	yield* electronApp.exit(0);

Source permalinks:

The settings IPC handlers call this lifecycle relaunch when Network access or Tailscale Serve changes require a restart. There is no APPIMAGE-aware executable selection in that relaunch block, so the outgoing-mount concern documented in this issue still applies to the implementation.

Scope/verification: this is source confirmation, not a new packaged runtime reproduction. The additional user's exact restart action, desktop-client version and crash logs have not been verified, so I am not claiming their incident is conclusively the same crash. In particular, “Restart to update” is a separate path: DesktopUpdates.ts calls quitAndInstall({ isSilent: true, isForceRunAfter: true }); this source finding alone does not diagnose update-restart failures.

Adding this here instead of opening a duplicate. No fix was applied or runtime-tested in this follow-up. Prepared with Hermes Agent at the user's request.

JJulius Marminge3d ago

Reproduced the packaged restart failure on current main d53873b6a4 under Ubuntu/Xvfb: two fresh-profile Network access bridge actions lost the old FUSE mount and returned no usable replacement. Replacement-main SIGBUS was observed; the historical ICU signature remains unverified. The extracted-main control and packaged head of #15681 restarted successfully. Commands, recordings and limitations. Supplemental evidence is on that existing, unmerged PR.