[Bug]: Updating Claude on Linux corrupts CLI symlink with T3CODE_ENV_XDG_DATA_HOME markers#32637

opened8d agobyTtobbelobb

Before submitting

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

Area

apps/desktop

Steps to reproduce

Start with a working native Claude Code installation at ~/.local/bin/claude.
Open T3 Code → Settings → Providers.
Confirm Claude is detected and authenticated (v2.1.308 in my case).
Click Update all.
Observe the notification:
Provider update failed — Claude: Update command completed, but T3 Code could not verify the provider version.
Claude now shows Not found, and running claude --version in a normal terminal returns claude: command not found.

This happened on my first attempt. I have not tested whether it reproduces consistently.

Expected behavior

T3 Code updates Claude without corrupting its executable symlink.
Environment-variable discovery returns a clean filesystem path.
If the update fails, the existing executable remains functional.
T3 Code reports an actionable error instead of leaving the CLI unusable.

Actual behavior

Inspecting the symlink:

bash

1	ls -l ~/.local/bin/claude

I got this:

1	torbjorn[~]$ ls -l ~/.local/bin/claude
2	lrwxrwxrwx 1 torbjorn torbjorn 115 nov 7 21:15 /home/torbjorn/.local/bin/claude -> ''\'''$'\a''__T3CODE_ENV_XDG_DATA_HOME_START__'$'\n\033'']0;printenv XDG_DATA_HOME'$'\a\033'']0;true'$'\a\033'']0;printf '\''%s'$'\n'\'' '\''/claude/versions/2.1.319'

Its target contains the following unexpected content (abridged to show the significant bytes):

text

1	$'\a'__T3CODE_ENV_XDG_DATA_HOME_START__
2	$'\n\033']0;printenv XDG_DATA_HOME
3	$'\a\033']0;true
4	$'\a\033']0;printf '%s'
5	...
6	/claude/versions/2.1.319

Instead of an absolute filesystem path, the symlink contains T3 Code environment-probe markers and terminal escape sequences.

The expected target version was also absent:

text

1	~/.local/share/claude/versions/
2	2.1.308
3	2.1.39

The original version remained installed, but the CLI was inaccessible through its normal command.

Impact

Major degradation or frequent failure

Version or commit

0.1.8-nightly.20261107.4327

Environment

Ubuntu Linux, x86_64

Logs or stack traces

shell

Screenshots, recordings, or supporting files

No response

Workaround

I can restore Claude v2.1.308 by repairing the symlink:

bash

1	ln -sfn "$HOME/.local/share/claude/versions/2.1.308" \
2	"$HOME/.local/bin/claude"

Ttobbelobb8d ago

Additional finding: the same environment-discovery bug also prevented Codex v0.167.0 from authenticating inside T3 Code.

Codex CLI and standalone codex app-server worked correctly.
T3's account/read requests failed immediately with workspace routing discovery failed.
Diagnostic logging confirmed that T3 passed malformed XDG_DATA_HOME and XDG_CONFIG_HOME values containing terminal escape sequences.
My Bash configuration has trap -- 'preexec' DEBUG.
Workaround confirmed: Completely quit T3 and launch it with:

bash

1	SHELL=/bin/sh \
2	XDG_CONFIG_HOME="$HOME/.config" \
3	XDG_DATA_HOME="$HOME/.local/share" \
4	/usr/bin/t3code

Codex then immediately showed Authenticated · ChatGPT Plus Subscription in T3.

This provides additional evidence for PR #32646. I have not tested the PR build itself, but the environment-probe fix appears likely to address both failures.

Ttobbelobb7d ago

Workaround until the PR is merged: I added some guards.

Earlier I had something like this in my .bashrc:

1	preexec() {
2	...
3	}
4	trap 'preexec' DEBUG

Now I have some guards around that:

1	preexec() {
2	# Never write terminal escape sequences to pipes or files.
3	[[ -t 1 ]] \|\| return
4	...
5	}
6	# Install the hook only for an interactive terminal.
7	if [[ $- == i && -t 1 ]]; then
8	trap 'preexec' DEBUG
9	fi

With the guards, it works as expected.