VSCode terminal crashing in specific case with TUI

[anthonyshew]

Original discussion: #10195

Verify canary release

• I verified that the issue exists in the latest Turborepo canary release.

Link to code that reproduces this issue

N/A

Which canary version will you have in your reproduction?

2.4.4

Environment information

See additional context for information.

Expected behavior

See additional context for information.

Actual behavior

See additional context for information.

To Reproduce

We don't have a clean reproduction for this case. See additional context for information.

Additional context

Summary

Sometimes after completing a task I get characters in the terminal or in the commit message.

Something like this:

35;95;33M35;94;33M35;94;34M35;93;34M35;93;35M35;92;35M35;91;36M35;91;37M35;90;37M35;89;37M35;89;38M35;88;38M35;88;39M35;88;40M35;88;41M35;88;42M35;88;43M

Sometimes they are there, sometimes they are not, I don't see a pattern. They can also appear after the task is completed with git commit --amend. In this case, all these symbols become a commit message, which requires additional changes

{
  "$schema": "https://turbo.build/schema.json",
  "tasks": {
    "pre-commit": {
      "dependsOn": ["lint", "typecheck"]
    },
    "pre-push": {
      "dependsOn": ["test"]
    },
    "build": {
      "dependsOn": ["test", "typecheck", "lint"],
      "outputs": ["dist/**"]
    },
    "build:dev": {
      "outputs": ["dist/**"]
    },
    "build:stage": {
      "dependsOn": ["test", "typecheck", "lint"],
      "outputs": ["dist/**"]
    },
    "build:analyze": {
      "dependsOn": ["build:dev"],
      "outputs": ["dist/**"]
    },
    "preview": {
      "persistent": true,
      "cache": false
    },
    "lint": {
      "dependsOn": ["^lint"]
    },
    "test": {
      "dependsOn": ["^test"]
    },
    "typecheck": {
      "dependsOn": ["^typecheck"]
    },
    "dev": {
      "persistent": true,
      "cache": false
    },
    "clean:turbo": {
      "cache": false,
      "outputs": []
    },
    "clean:node-modules": {
      "cache": false,
      "outputs": []
    },
    "sb": {
      "cache": false
    }
  },
  "ui": "tui"
}

Additional information

- Turbo: 2.4.4
- Node: 18.20.3
- OS: macos Sequoia 15.0.1
- Terminal: iTerm2 3.5.11
- Zsh 5.9 (arm64-apple-darwin24.0)

Example

No response

[anthonyshew]

Bringing error logs that were DM'ed to me here:

panicked at crates/turborepo-lib/src/commands/run.rs:64:42:
render thread panicked: JoinError::Panic(Id(46), ...)"""

panicked at crates/turborepo-vt100/src/grid.rs:873:18:
called `Option::unwrap()` on a `None` value"""

[anthonyshew]

Our current theory is that the task is writing some bad character to the terminal. We're not handling it well enough, so a crash occurs. We think there's some race condition in one of our underlying libraries but can't confirm without more information.

Can you give us some information about what tools are being used in the task that is crashing? Are there any out-of-the-ordinary characters in the log output? More generally, we're looking for anything that could be atypical being written to the terminal.

[soulr344]

Attaching the logs for the full crash here:

logs.txt
report-84e677ae-a776-4ff9-afa2-aac587bca2ea.txt
report-277cdae7-8547-4314-ae38-6fdb3439d2bf.txt

(Last 2 files have been renamed from .toml to .txt)

[rettimo]

I can also say that this happens regardless of which terminal is used. In my team, this happens to everyone, so I had to switch to "ui": "stream". Let me know what could be the problem or how can I write my own ui.

[anthonyshew]

@rettimo @soulr344 Can you provide full reproductions?

[soulr344]

@anthonyshew i did some random stuff and figured out that it happens when turbo is killed

the reproduction steps are: (i verified that this happens on all turborepo projects that i have, all of them are in turbo v 2.4.4).

• run the dev command in any turbo repo project with tui enabled
• kill the process with pkill turbo

Then try hovering the mouse over the terminal, it should go crazy.

Let me know if this works. Incase it doesn't, I'll try finding some other way to reproduce.