Repository navigation
[Bug]: Linux -> child processes inherit ELECTRON_RUN_AS_NODE=1 and break other Electron apps #1162
Description
Activity
The terminal environment sanitizer explicitly blocks
ELECTRON_RUN_AS_NODEbefore spawning child processes, so this is fixed.This was closed as part of a large repo-wide maintenance sweep. If you think it's still relevant, please reopen.
This fix is good, but the scope is narrow, and this kind of issue still reproduces on v0.0.36, through a path the terminal fix doesn't cover: agent sessions bypass the sanitizer entirely. Creating a shared helper to be able to cover a broader scope seems like a small fix IMO.
From a Claude agent session's shell:
$ env | grep -E '^(APPIMAGE|APPDIR|OWD|LD_LIBRARY_PATH|ELECTRON_RUN_AS_NODE)=' APPDIR=/tmp/.mount_t3code26Eb74 OWD=/home/rafa LD_LIBRARY_PATH=/tmp/.mount_t3code26Eb74/usr/lib APPIMAGE=/home/rafa/.local/bin/t3code.AppImage ELECTRON_RUN_AS_NODE=1 $ obsidian Error: Cannot find module 'electron' # same failure as the original reportPATHalso still carries the/tmp/.mount_*entries (the #1699 symptom).Root cause: the sanitizers from 4b4abcd (
TERMINAL_ENV_BLOCKLIST,
stripAppImageRuntimeEnv) are private toapps/server/src/terminal/Manager.ts
and only run on the PTY spawn path. Provider sessions build their env in
apps/server/src/provider/ProviderInstanceEnvironment.ts, where
mergeProviderInstanceEnvironmentdefaultsbaseEnvtoprocess.envand
returns it unchanged when no custom environment is configured.ClaudeDriver.ts
(and the other four drivers) pass that straight into the agent spawn, so every
command an agent runs inherits the Electron/AppImage runtime state.Suggested fix: extract the terminal sanitizer into a shared helper and apply
it inmergeProviderInstanceEnvironmentbefore layering the explicitly
configured provider variables. One chokepoint covers all five drivers, and the
desktop→backend spawn (which legitimately needsELECTRON_RUN_AS_NODE=1) is
untouched.Related: #2867 is the same class of leak on the provider boundary — packaged-backend
cwd escaping where this is packaged-backend env. A shared "sanitize before provider
spawn" chokepoint is a natural place to address both.Could this be reopened? I'm happy to re-test a build.
Reacted by Xian Zhang and Duncan Overbrucki can still see the leakage in a Claude session (not the terminal), on 0.0.44 (Linux AppImage).
Agent cannot run obsidian cli anymore due to the leakage.
Before submitting
Area
apps/desktop
Steps to reproduce
env | grep ELECTRON_RUN_AS_NODEobsidian helpELECTRON_RUN_AS_NODE=1Cannot find module 'electron'env -u ELECTRON_RUN_AS_NODE obsidian helpExpected behavior
ELECTRON_RUN_AS_NODE=1should stay scoped to the internal process that needs it and should not be inherited by external commands/apps launched from T3 Code.Actual behavior
On Linux desktop builds, commands launched from the T3 Code environment can inherit
ELECTRON_RUN_AS_NODE=1.That breaks unrelated Electron apps started from that environment. In my case,
obsidian helpfails with:Error: Cannot find module 'electron'Impact
Major degradation or frequent failure
Version or commit
0.0.11
Environment
linux-lts 6.18.18-1, Hyprland 0.54.2, Node.js 22.22.1, NPM 11.11.1
Logs or stack traces
Screenshots, recordings, or supporting files
No response
Workaround
This does not seem to be a global OS/session issue.
Hyprlanddoes not haveELECTRON_RUN_AS_NODEt3-code-desktopprocess does not have it.../resources/app.asar/apps/server/dist/index.mjsdoes have itSo the variable appears to leak from the internal server process into child commands.