Sign up
View stargazersSign up

Worktree setup fails with Nushell because completion tracking uses POSIX syntax#24423

opened22d agobyMmirsella

What happens

My default shell is Nushell. Creating a thread with a new worktree fails during project setup.

T3 opens the setup terminal in Nushell, but uses a POSIX completion wrapper. Nushell accepts the simple wrapper shown below, but passes "$?" literally to printf. T3 expects a numeric exit code, so it never recognizes that completion marker.

Environment

  • Linux
  • Nushell 0.116.1
  • Observed with T3 0.1.3-nightly.20261024.3604
  • T3 running as a user systemd service with SHELL=/bin/nu

Steps to reproduce

  1. Start T3 with SHELL pointing to Nushell, without a workaround that switches script terminals to another shell.

  2. Configure a synchronous worktree setup script:

    json
    1{
    2 "scripts": [
    3 {
    4 "id": "setup",
    5 "name": "Setup",
    6 "command": "echo setup-ok",
    7 "icon": "configure",
    8 "runOnWorktreeCreate": true,
    9 "async": false
    10 }
    11 ]
    12}

  3. Create a new thread using a new worktree.

Expected behavior

The setup command runs and T3 records its exit status.

Cause

In ProjectSetupScriptRunner.ts, resolveCompletionShell recognizes Fish and PowerShell, but treats Nushell as POSIX.

wrapCommandForCompletion consequently sends a wrapper equivalent to:

sh
1( echo setup-ok
2); printf '\n__T3_SETUP_DONE___token:%s\n' "$?"

Correction to the original report: this is not necessarily a parse error. On Nu 0.116.1, the example prints __T3_SETUP_DONE___token:$?, not a numeric status. A failing external command can also stop evaluation before printf runs. Changing only the project command to bash -c '...' does not repair completion tracking.

Possible fixes

Support Nushell in the completion wrapper, including exit-status handling.

Alternatively, allow an explicit shell for project scripts, separate from the interactive terminal shell. That would let users keep Nushell for regular terminals and run setup hooks through Bash.

Local workaround and verification

I removed the earlier workaround that replaced project-script terminals with Bash. All terminals now remain Nushell.

A local Nu adapter records the per-run T3 marker in a pre_execution hook, then prints the marker with LAST_EXIT_CODE in a pre_prompt hook. This handles both successful commands and commands that fail before T3's printf. Separately, my project's setup command now uses sh -c 'exec sh "$T3CODE_PROJECT_ROOT/scripts/setup-worktree.sh"' so POSIX environment expansion happens inside sh rather than Nu.

Interactive PTY checks covered the actual setup script in a fresh Git worktree with spaces in its path, file copies and symlinks, rerunning setup, exit code 7, and a missing command. Checks using the full applied Nu configuration also passed. These are shell/fixture tests, not an end-to-end test of thread creation through T3.

I have not established that the October 24 nightly introduced this bug. ProjectSetupScriptRunner.ts is identical at the installed October 21 and October 24 release commits.

  • #194 requested Nushell support, primarily around CLI discovery.
  • #309 reported Codex detection failing with Nushell on macOS.
  • #7846 reported Nushell PATH hydration failures and was addressed by #7894.

This report concerns a different code path: the completion wrapper for worktree setup scripts still assumes POSIX syntax when the terminal shell is Nushell.

KKenDJohnson12d ago
Synced from GitHub

Reproduced on macOS as well (T3 Code desktop v0.1.6, Nushell 0.116.1 as the login shell). On current main (edc37c96c), a sync worktree setup action echo setup-ok prints __T3_SETUP_DONE___<token>:$? and thread start never proceeds. Before and after #23576, every shell other than fish/PowerShell/cmd gets the POSIX printf … "$?" wrapper, so this appears whenever the setup terminal runs nu.

A Nushell wrapper fixes it:

nu
1let __t3c = try {
2<command>
30 } catch {|e| if $e.exit_code? == null { print -e $e.rendered }; $e.exit_code? | default 1 }; print $"\n<sentinel>($__t3c)"

try is required because nu skips the rest of the input after a failing command. Failing externals report $e.exit_code; other errors (command not found, error make) are printed, since catch would hide them, and report 1.

Verified with real nu 0.116.1 in a PTY: success → 0, a command exiting 7 → 7, command not found → 1 with the error shown; multi-line commands and trailing comments work; stdout stays a TTY. End to end via t3 thread start --worktree on a dev server: before, it hangs at :$?; after, setup reports 0 and the agent starts, and a setup command exiting 3 stops the thread with "Setup script exited with 3."

Limitation: actions must be valid Nushell. POSIX-only syntax such as a && b fails to parse, so no status is printed, the same class as a syntax error in a POSIX shell.