stdout/stderr are pipes instead of TTY, causing isatty() to return False

[barad1tos]

Issue Description

Issue Description

In Ghostty, stdout (fd1) and stderr (fd2) are pipes instead of direct PTY connections. This causes isatty() to return False for these file descriptors, which breaks color output detection in virtually all CLI tools that check for terminal capability.

This affects:

• Python's Rich library (Console.is_terminal returns False)
• Homebrew (brew update shows no colors)
• pytest, pip, npm, cargo, and countless other CLI tools
• Any program using ANSI color detection

The issue persists regardless of:

• Shell used (zsh, bash)
• Shell integration setting (enabled or shell-integration = none)
• TERM value (xterm-ghostty or xterm-256color)
• Shell configuration files (tested with zsh -f and bash --noprofile --norc)

Expected Behavior

File descriptors 0, 1, and 2 should all be TTY devices:

$ ls -la /dev/fd/
0 - crw--w---- tty
1 - crw--w---- tty
2 - crw--w---- tty

$ python3 -c "import os; print('fd0:', os.isatty(0), 'fd1:', os.isatty(1), 'fd2:', os.isatty(2))"
fd0: True fd1: True fd2: True

This is the behavior in Terminal.app and Warp on the same system.

Actual Behavior

stdout and stderr are pipes instead of TTY:

$ ls -la /dev/fd/
0  - crw--w---- tty    ← stdin = TTY ✓
1  - p-w--w----        ← stdout = PIPE ✗
2  - p-w--w----        ← stderr = PIPE ✗
13 - crw--w---- tty    ← real TTY exists here
14 - crw--w---- tty    ← real TTY exists here

$ python3 -c "import os; print('fd0:', os.isatty(0), 'fd1:', os.isatty(1), 'fd2:', os.isatty(2))"
fd0: True fd1: False fd2: False

Reproduction Steps

1. Open Ghostty
2. Run: ls -la /dev/fd/
3. Observe that fd1 and fd2 show "p-w--w----" (pipe) instead of "crw--w----" (tty)
4. Run: python3 -c "import os; print('fd0:', os.isatty(0), 'fd1:', os.isatty(1), 'fd2:', os.isatty(2))"
5. Observe: fd0: True fd1: False fd2: False
6. For comparison, run the same commands in Terminal.app - all three are True

Ghostty Logs

No relevant logs - this is not a crash or error, but incorrect PTY/pipe configuration.

Ghostty Version

Tested on both:
- Ghostty 1.2.3 (stable)
- Ghostty tip: b9ad1f05e / Build 13676

OS Version Information

macOS 26.2 (Build 25C56), Darwin 25.2.0, arm64 (Apple M1 Pro)

(Linux only) Display Server

None

(Linux only) Desktop Environment/Window Manager

No response

Minimal Ghostty Configuration

# Issue reproduces with completely empty config
# Also tested with:
shell-integration = none
term = xterm-256color

Additional Relevant Configuration

Shell: zsh 5.9 (also tested with /bin/bash)
Issue reproduces with:

• zsh -f (no config)
• /bin/bash --noprofile --norc (no config)

I acknowledge that:

• I have reviewed the FAQ and confirm that my issue is NOT among them.
• I have searched the Ghostty repository (both open and closed Discussions and Issues) and confirm this is not a duplicate of an existing issue or discussion.
• I have checked the "Preview" tab on all text fields to ensure that everything looks right, and have wrapped all configuration and code in code blocks with a group of three backticks (```) on separate lines.

[trag1c]

I cannot reproduce this (Apple M2, macOS 26.2):

How did you install and how do you open Ghostty?

[barad1tos]

Installation: brew install --cask ghostty

How I open:

1. Spotlight -> Cmd+Space -> Ghostty
2. Also in terminal open /Applications/Ghostty.app
3. Finder -> Applications -> Ghostty

Versions tested:

1. 1.2.3 (stable) — same issue
2. tip (b9ad1f0 / Build 13676) — same issue

System:

• macOS 26.2 (Build 25C56)
• Apple M1 Pro

[mitchellh]

I tested your exact reproductions (ls and the python script) and this doesn't reproduce on my machine either. macOS 26.2 and Apple M4 Max. I tried with bash, zsh, and Nu in case the startup shell mattered, too.

Moving this to Q&A since this appears to somehow be a system issue. If we're wrong we can move it back.

[barad1tos]

I don't really know what causes this behavior, but here's one of consequence

[barad1tos]

equal picture but in Warp

[barad1tos]

Hi again. Sorry for the noise, I have found the reason. It was my own pre-cmd hooks that used to tee my commands. After deleting this, everything went well.