vp hangs when spawned by lefthook (opens /dev/tty)

[spalger]

Describe the bug

vp commands hang indefinitely when spawned as child processes by lefthook git hooks. The same commands complete in ~1 second when run directly in a terminal.

# Works fine (~1s):
vp run typecheck

# Hangs indefinitely:
git add lefthook.yml && npx lefthook run pre-commit

Both vp run <script> and vp test are affected.

Root cause

lsof on the hanging vp process shows it opens /dev/tty directly (fd 9), bypassing stdin:

COMMAND   PID    USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
vp      11794 spalger    0u   CHR   16,0      0t0  895 /dev/ttys000
vp      11794 spalger    1u   CHR   16,0      0t0  895 /dev/ttys000
vp      11794 spalger    2u   CHR   16,0      0t0  895 /dev/ttys000
vp      11794 spalger    9u   CHR    2,0     0t26  335 /dev/tty

Lefthook allocates pseudo-TTYs for child processes. When vp opens /dev/tty and reads from it, it blocks because there's no input on the pseudo-TTY.

This is partly a lefthook issue too — lefthook gives non-interactive child processes a controlling terminal even though it already treats them as non-interactive (null stdin per evilmartians/lefthook#732). But vp could also handle the case where /dev/tty isn't truly interactive more gracefully, rather than blocking indefinitely.

Workaround

Redirect stdin from /dev/null:

pre-commit:
  commands:
    typecheck:
      run: vp run typecheck </dev/null
    test:
      run: vp test </dev/null

Reproduction

Can't manage to run curl -fsSL https://vite.plus | bash in stackblitz sandboxes...

Steps to reproduce

• Install lefthook npm install --save-dev lefthook
• Write lefthook.yml file

lefthook.yml:

pre-commit:
  commands:
    typecheck:
      run: vp run typecheck

• Run npx lefthook run pre-commit

System Info

VITE+ - The Unified Toolchain for the Web

Environment:
  Version  24.14.1
  Source   lts

Tool Paths:
  node  /Users/spalger/.vite-plus/js_runtime/node/24.14.1/bin/node
  npm   /Users/spalger/.vite-plus/js_runtime/node/24.14.1/bin/npm
  npx   /Users/spalger/.vite-plus/js_runtime/node/24.14.1/bin/npx

vp v0.1.16

Local vite-plus:
  vite-plus  Not found

Tools:
  vite             Not found
  rolldown         Not found
  vitest           Not found
  oxfmt            Not found
  oxlint           Not found
  oxlint-tsgolint  Not found
  tsdown           Not found

Environment:
  Package manager  pnpm v10.33.0
  Node.js          v24.14.1

Used Package Manager

pnpm

Logs

Validations

• Read the Contributing Guidelines.
• Check that there isn't already an issue for the same bug.
• Confirm this is a Vite+ issue and not an upstream issue (Vite, Vitest, tsdown, Rolldown, or Oxc).
• The provided reproduction is a minimal reproducible example.

[claude]

Analysis

Root cause

The hang originates in crates/vite_shared/src/header.rs — specifically the query_terminal_colors() function, called from vite_plus_header() → print_runtime_header() → every command dispatch (including vp run and vp test).

Before executing any command, vp renders its header with gradient colors that match the terminal's color scheme. To do this, query_terminal_colors():

1. Opens /dev/tty directly (this is fd 9 in the lsof output)
2. Sets the terminal to raw mode via tcsetattr
3. Writes an OSC color query (ESC]10;?, OSC4 palette queries, and a DA1 sentinel)
4. Polls /dev/tty for responses with a 200ms timeout

There is already a guard — is_osc_query_unsupported() — intended to skip the query in non-interactive environments:

fn is_osc_query_unsupported() -> bool {
    static UNSUPPORTED: OnceLock<bool> = OnceLock::new();
    *UNSUPPORTED.get_or_init(|| {
        if !std::io::stdout().is_terminal() || !std::io::stdin().is_terminal() {
            return true;  // This is what the </dev/null workaround triggers
        }
        // CI checks, Warp, tmux, SSH, etc.
        ...
    })
}

The workaround (</dev/null) works because redirecting stdin from /dev/null makes stdin().is_terminal() return false, so the guard returns true and /dev/tty is never opened.

Why lefthook breaks this: Lefthook allocates a pseudo-TTY for child processes, so vp's stdin and stdout are PTY slaves. is_terminal() returns true for both — the guard does not trigger. Then query_terminal_colors() opens /dev/tty (same PTY slave), sends the OSC query through to lefthook's PTY master, and polls for a response.

The 200ms timeout via poll() should theoretically prevent an indefinite hang, but certain PTY configurations on macOS can cause poll() to misbehave — either returning POLLIN immediately with the echoed query bytes, or causing read() to block even after poll() reports ready. In either case, the timeout mechanism can fail to terminate the wait.

Relevant files

• crates/vite_shared/src/header.rs — query_terminal_colors(), is_osc_query_unsupported(), and the TtyReader with its 200ms timeout
• crates/vite_global_cli/src/cli.rs — print_runtime_header() (line 2101) calls vite_plus_header() before every command including vp run and vp test
• crates/vite_global_cli/src/command_picker.rs — should_enable_picker() has a similar PTY risk for bare vp, but is protected by the args.len() == 1 check

Fixable? Yes

Complexity: Low — the fix is contained to is_osc_query_unsupported() in header.rs.

Implementation plan

Option 1 (recommended — process group check): Check if vp is in the foreground process group of its controlling terminal. If not, we are running in an automated context (git hook runner allocating a PTY, etc.) and OSC queries will not be answered:

// In is_osc_query_unsupported(), after the existing is_terminal() checks:
#[cfg(unix)]
{
    use std::os::fd::BorrowedFd;
    // SAFETY: fd 0 is valid since is_terminal() returned true above
    let stdin_fd = unsafe { BorrowedFd::borrow_raw(0) };
    if let Ok(fg_pgrp) = nix::unistd::tcgetpgrp(stdin_fd) {
        if fg_pgrp != nix::unistd::getpgrp() {
            return true; // Not foreground — no interactive user on the other end
        }
    }
}

This is a clean, general solution: it correctly identifies any scenario where the process is not the foreground process group of the terminal (lefthook, CI runners allocating PTYs, background processes, etc.) without enumerating specific tools.

Option 2 (belt-and-suspenders — thread-level timeout): Wrap query_terminal_colors() in a spawned thread with a strict wall-clock deadline. This defends against any future poll() misbehavior regardless of PTY configuration:

fn query_terminal_colors_safe(palette_indices: &[u8]) -> (Option<Rgb>, Vec<(u8, Rgb)>) {
    let indices = palette_indices.to_vec();
    let (tx, rx) = std::sync::mpsc::channel();
    std::thread::spawn(move || {
        let _ = tx.send(query_terminal_colors(&indices));
    });
    rx.recv_timeout(std::time::Duration::from_millis(250))
        .unwrap_or((None, vec![]))
}

I would recommend implementing both: Option 1 to fast-path the common automated case, and Option 2 as a true defensive backstop for any edge case that slips through.

No new dependencies needed

The nix crate is already used in crates/vite_shared/src/header.rs (for poll, tcgetattr, tcsetattr), so nix::unistd::tcgetpgrp is available without adding anything.