[Bug]: Claude and Codex auth probes time out through mise shims; absolute executable paths restore authentication #16106

Activity

1. juliusmarminge commented on Oct 5, 2026

   

   juliusmarminge

   on Oct 5, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks for the careful investigation, @vayllon301, especially the direct shim timing and the absolute-path check!

   What I found

   • This looks like a provider launch hang rather than a missing Claude or Codex login. The cached messages match the probe timeouts on nightly 0.0.46-nightly.20261005.2676 (78122305) and current main (e22c880434); those probe files are unchanged between the two.
   • Claude: installed=true, version=null, and Timed out while running command is the --version probe hitting DEFAULT_TIMEOUT_MS (4s) in checkClaudeProviderStatus. That branch only runs once the process has started and not exited; a missing claude would be reported as not found on PATH.
   • Codex: Timed out while checking Codex app-server provider status is the whole codex app-server handshake hitting AUTH_PROBE_TIMEOUT_MS (10s). The version comes from that handshake, so it stays null. The "not authenticated, run codex login" message is a separate branch.
   • On Linux both probes spawn the configured binaryPath with shell: false. The child-process spawner starts a new session (detached defaults on outside Windows) and leaves stdin as an open pipe nothing writes to or closes. Your ~30ms Python run used the same environment and cwd but not those spawn flags.
   • A likely cause is mise blocking before exec when stdin isn't a terminal and there's no controlling terminal (its trust/install prompts can wait on stdin or /dev/tty). For Codex that would also hold the JSON-RPC stdin, so app-server never starts. A less likely alternative on Omarchy is the ~/.local/bin/claude bash stub (exec mise x -- claude) looping when ~/.local/bin is ahead of the shims, though you reported the names resolving to the shim.
   • Not a duplicate: [Bug]: One transient probe timeout leaves Claude stuck on "Could not verify Claude authentication status" for hours (cause swallowed, no demand-less recheck) #13635 is a capabilities warning after a probe that did return a version, and [Bug]: Cursor provider (V2 SDK) ignores existing Cursor CLI/SDK login and forces T3 sign-in or CURSOR_API_KEY #15781 is the Cursor report, which doesn't use this spawn path.

   If you have a moment, these would help narrow it down:

   • type -a claude and type -a codex from the service environment.
   • During a probe, cat /proc/<child>/cmdline and ls -l /proc/<child>/fd/0 to see whether it's a looping stub or mise blocked on the stdin pipe.

   In the meantime, the absolute install paths you used are a working workaround.

   Likely fix area

   Options include making the one-shot probes not hold an open stdin (while codex app-server still needs its pipe), and making the timeout message say the probe timed out and point at the provider binary path setting, rather than leaving auth=unknown to read like a logged-out account.

   A maintainer will decide on the fix direction.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 5, 2026
3. rubenmeza commented on Oct 5, 2026

   

   rubenmeza

   on Oct 5, 2026

   More actions

   On Omarchy, I can confirm it's the looping stub, not mise blocking on stdin.

   Setup: Omarchy 4.0.4, t3code-bin 0.0.45 (Omarchy package), mise 2026.10.0, Linux 7.2.5.
   ~/.local/bin/{claude,codex,gh} are Omarchy omarchy-mise-install stubs:
   mise use -g --quiet X || exit 1; exec mise x X -- X "$@".

   What happens:

   • The desktop app copies only PATH from $SHELL -ilc (LOGIN_SHELL_ENV_NAMES in
     apps/desktop main). It does not copy mise's activation state (__MISE_DIFF).
   • My rc puts ~/.local/bin ahead of the mise shims.
   • Without __MISE_DIFF, mise x inserts the tool's bin dir where the shims entry sits, which is
     behind ~/.local/bin. So the bare claude resolves to the stub again, and the stub execs itself
     forever in the same PID.

   Evidence:

   • Under the server's own PATH (from /proc/<t3 server pid>/environ), running the stub with
     </dev/null and no TTY: claude --version times out (rc=124 at 8s). MISE_DEBUG=1 on the gh stub shows
     ARGS: mise x gh -- gh --version repeating about 3 times a second.
   • ps shows one PID that is alive for minutes, while its mise use -g child is always freshly started.
   • Adding __MISE_DIFF back, or putting the shims before ~/.local/bin, makes it return in about 0.2s.
     I ran both cases from the same context, with no controlling TTY and stdin </dev/null. Only
     __MISE_DIFF changed the result (env -u __MISE_DIFF mise x gh -- gh --version gives rc=124;
     with the variable it works). So stdin/TTY is not the cause.
   • gh hits the same loop. That makes every GitHubCli call (PR lookup) hit its 30s timeout.

   Omarchy fix: omacom/omarchy#7234 (PRs #8692, #9175, #13769).

   T3-side suggestions:

   1. When a probe times out, show the resolved executable path and suggest the provider "Binary path"
      setting. Today it reads as an auth problem.
   2. Kill the whole process group on probe timeout, so a looping stub can't outlive the probe.
   3. Consider also forwarding __MISE_DIFF, __MISE_ORIG_PATH and __MISE_SESSION from the login-shell capture,
      or resolving provider binaries with command -v in that same login shell.
   4. Add a "GitHub CLI path" setting. gh is spawned by bare name (GitHubCli.executeRaw, command "gh")
      and there's no override, unlike the providers.

   Workaround: set the absolute binaryPath (mise installs/<tool>/latest/...) as reported above.
   For gh, fix the PATH order.
4. Sergiogd112 commented on Oct 8, 2026

   

   Sergiogd112

   on Oct 8, 2026

   More actions

   Hit the same symptom on v0.0.45 (Linux x64, desktop app), and in this case it has a confirmed cause, which may help explain some of the other mise reports here.

   Symptom: Claude shows "Unavailable — Claude Agent CLI is installed but failed to run. Timed out while running command." claude --version works instantly in a terminal.

   Cause: claude on PATH was a user wrapper script (~/.local/bin/claude) that delegated through mise:

   export MISE_MINIMUM_RELEASE_AGE=0
   mise use -g "claude" || exit 1
   exec mise x "claude" -- "claude" "$@"

   The desktop server's PATH had ~/.local/bin before ~/.local/share/mise/installs/claude/latest. Because the install dir was already on PATH, mise x didn't move it to the front, so claude resolved back to the wrapper. Result: infinite recursion (mise use -g claude repeating forever) until the 4s DEFAULT_TIMEOUT_MS in providerSnapshot.ts fired. It looks fine in an interactive shell only because PATH is ordered differently there.

   Repro: run the wrapper with the server process's PATH and stdout piped (as spawnAndCollect does): env -i PATH=<server PATH> HOME=$HOME ~/.local/bin/claude --version | cat hangs indefinitely.

   Fix (user side): change the last line to exec "$(mise which claude)" "$@", which resolves the real binary directly. With the server's PATH it now returns in ~75ms. Setting an absolute Claude binary path in T3 settings also works, as noted above.

   Possible T3 improvements: the probe can't tell a hang from slowness, so a message like "claude --version did not exit within 4s; check for wrappers/shims that recurse or wait on the network" would point people in the right direction. Also related: #7230 (a timed-out probe stays cached as an error).

   Diagnosed via t3 triage with Claude Code (Claude Opus 5.5).
5. t3dotgg

   closed this as completedin #19340on Oct 14, 2026