Question about garbled ANSI codes when running 'gh' inside fzf's execute action.

[LangLangBart]

Run the command below and notice the issue:

output=$(fzf --bind "start:execute(gh --version)+accept")
# ^[]11;rgb:2137/22df/298c^G^[[2;1R^[]11;rgb:2137/22df/298c^G^[[2;1Rgh version 2.76.0 (2025-07-17)
# https://github.com/cli/cli/releases/tag/v2.76.0
# 11;rgb:2137/22df/298c[2;1R11;rgb:2137/22df/298c[2;1R
echo $?
# 1

---

It used to work fine with older gh versions:

output=$(fzf --bind "start:execute(bin/gh --version)+accept")
# gh version 2.69.0-3-gcf3f0ee6b8dd (2025-07-23)
# https://github.com/cli/cli/releases/latest
echo $?
# 0

The problematic behavior in gh was introduced in two stages:

First: gh itself began querying the terminal. This could still be suppressed with NO_COLOR=1.

• Ref: cli/cli · Thematic Headers · 21/Mar/2025

output=$(fzf --bind "start:execute(bin/gh --version)+accept")
# gh version 2.69.0-4-g6355e54e3cc1 (2025-07-23)
# https://github.com/cli/cli/releases/latest
# 11;rgb:2137/22df/298c[21;1R
echo $?
# 1

# ✅ NO_COLOR=1
output=$(fzf --bind "start:execute(NO_COLOR=1 bin/gh --version)+accept")
# gh version 2.69.0-4-g6355e54e3cc1 (2025-07-23)
# https://github.com/cli/cli/releases/latest
echo $?
# 0

Second: A new dependency, 'bubbletea', was added. It performs its own terminal query, which cannot be disabled by gh-specific env like 'NO_COLOR', but can be stopped with TERM=dumb.

• Ref: cli/cli · Accessible Prompter · 31/Mar/2025

output=$(fzf --bind "start:execute(bin/gh --version)+accept")
# ^[]11;rgb:2137/22df/298c^G^[[59;1R^[]11;rgb:2137/22df/298c^G^[[59;1Rgh version 2.69.0-28-g202c1ad16b78 (2025-07-23)
# https://github.com/cli/cli/releases/latest
# 11;rgb:2137/22df/298c[59;1R11;rgb:2137/22df/298c[59;1R
echo $?
# 1

output=$(fzf --bind "start:execute(NO_COLOR=1 bin/gh --version)+accept")
# gh version 2.69.0-28-g202c1ad16b78 (2025-07-23)
# https://github.com/cli/cli/releases/latest
# 11;rgb:2137/22df/298c[59;1R
echo $?
# 1

# ✅ TERM=dumb
output=$(fzf --bind "start:execute(TERM=dumb bin/gh --version)+accept")
# gh version 2.69.0-28-g202c1ad16b78 (2025-07-23)
# https://github.com/cli/cli/releases/latest
echo $?
# 0

---

Using an fzf version prior to the linked commit below results in a nonzero exit status but no
garbled ANSI codes, as long as output is not redirected to /dev/tty.

• Ref: junegunn/fzf · execute /dev/tty · 23/May/2024

../fzf/bin/fzf --version
# 0.52.1 (d4216b0d)

output=$(../fzf/bin/fzf --bind "start:execute(bin/gh --version)+accept")
echo $?
# 1

output=$(../fzf/bin/fzf --bind "start:execute(bin/gh --version >/dev/tty)+accept")
# ^[]11;rgb:2137/22df/298c^G^[[7;1R^[]11;rgb:2137/22df/298c^G^[[7;1Rgh version 2.69.0-28-g202c1ad16b78 (2025-07-23)
# https://github.com/cli/cli/releases/latest
# 11;rgb:2137/22df/298c[7;1R11;rgb:2137/22df/298c[7;1R
echo $?
# 1

---

This issue does not occur with execute-silent. It also does not occur when piping gh into another command, such as cat, or when using TERM=dumb. However, these seem more like workaround fixes than real solutions.

@junegunn, what is the best way for a user to address this? Should I file an issue with the gh team, or is there an fzf-native approach to handle this interaction and prevent the terminal's response (escape codes) from leaking into the output?

I am a bit unsure about who needs to take action in this case and am just looking for guidance.

[junegunn]

Thanks for the heads-up.

Yes, I can reproduce the problem (but not when I'm on tmux for some reason).

is there an fzf-native approach to handle this interaction and prevent the terminal's response (escape codes) from leaking into the output?

I really hope so, but I'm not sure at this point. I'll have to investigate.

[junegunn]

A minimal repro (without fzf):

gh --version > /dev/tty

[LangLangBart]

Thanks. Should I file a report with them, or would you prefer to do it since you can probably explain the issue better?

[LangLangBart]

Never mind, its already reported:

• gh produces incorrect terminal escape sequences when running in GNU screen with TERM=xterm-16color cli/cli#11008
• Visible escape codes in urxvt with transparent background break interactive prompts (e.g., gh pr create) with gh v2.70.0 cli/cli#10830
• ...

[junegunn]

While the problem is reproducible without fzf, redirecting the output of gh to /dev/tty is likely an uncommon and unexpected use case, so they may see this as a non-issue. I don't have high hopes for them to fix it promptly. fzf is probably an outlier here. And we don't want to revert 3dee877 for a good reason. Anyway, thanks a lot for looking into it and reporting our case!