Repository navigation
[Feature]: Support custom code editors via VISUAL/EDITOR environment variables #1068
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I am describing a concrete problem or use case, not just a vague idea.
Area
apps/desktop
Problem or use case
The list of supported editors is hardcoded. When users need a different editor (e.g., WebStorm, #428), it requires a code change. As adoption grows, individual editor requests won't scale.
Proposed solution
Read the VISUAL / EDITOR environment variable and offer it as an additional option in the editor picker — not as a replacement for the current default. The built-in list and its default (Cursor) stay as-is. If the env var points to a known editor, reuse its icon/config. If unknown, show it as a generic "System Editor" option that launches with the directory path as the argument.
Why this matters
Users of less common editors can use t3code without waiting for their editor to be explicitly added. Contributors don't need to maintain an ever-growing editor list.
Smallest useful scope
Read VISUAL (falling back to EDITOR), check if the command is on PATH, and surface it as one extra option in the picker. No settings UI needed.
Alternatives considered
Adding editors one by one to the hardcoded list (current approach, see #428). A dedicated settings UI for custom editors — viable but heavier for what environment variables already solve.
Risks or tradeoffs
Some editors may not follow the convention of accepting a directory path as an argument. The generic fallback can't support editor-specific flags like --goto.
Examples or references
Contribution
- I would be open to helping implement this.
Activity
0pilatos0 commentedon Mar 20, 2026
okey... this is getting out of hand, how the hell is everyone creating random pr's for this without triage....
Sah-Nikhil commentedon Mar 22, 2026
Hi, I've implemented a possible approach in my fork with a Custom Editor executable path flow.
It keeps the built-in editor list/defaults unchanged, but adds a “Custom Editor” option that launches any editor from a user-specified path (e.g. WebStorm, custom installs).
This works in both desktop (screenshot is from Windows) and server/web launch paths and doesn’t require adding new hardcoded editor IDs.
This could complement
VISUAL/EDITORby providing an explicit, user-configurable fallback when env vars aren’t set or don’t match the desired editor.env vars could act as initial defaults, with explicit settings providing a more deterministic override and making debugging easier when launch args differ.
(currently, my implementation only covers the custom executable path method)
Happy to open a PR to upstream this, if this direction makes sense. Or combine both approaches (env vars as initial autofill + settings override).
Screenshots below:
Settings
Desktop (Windows)
Web
edit: fixing typos
lmerz1 commentedon May 11, 2026
For what it's worth, I'd also very much like to have this feature, but the original suggestion misses that "opening
$EDITOR" is a twofold requirement: Determining the actual editor via environment variable is the easier part, but for terminal-based editors, a GUI application also has to detect (or query the user for) their preferred terminal emulator application if the calling app doesn't want to open the (typically full-sized) terminal itself.For example, on macOS most people are not using Terminal.app, but probably Ghostty/Kitty/iTerm2/…, so T3 Code would probably have to either
$EDITORwith e.g. the/path/to/file:line:columnformat.juliusmarminge commentedon Jun 9, 2026
Duplicate of #433
Same capability — register a custom editor for the Open button instead of the hardcoded list; #433 is canonical and also covers editing/removing entries. The VISUAL/EDITOR env-var detection is a good implementation candidate for it.