`set -Ua fish_features no-keyboard-protocols` not work

[nonkr]

fish version 4.0.2, terminal is WindTerm 2.7.0
I already run set -Ua fish_features no-keyboard-protocols, and restarted fish, but still have �]133;A;special_key=1 in prompt.

[krobelus]

this is a bug in WindTerm's OSC parser. Similar to kingToolbox/WindTerm#188 and others. Possible workaround:

diff --git a/src/terminal.rs b/src/terminal.rs
index ef2d995041..fc92bbc60d 100644
--- a/src/terminal.rs
+++ b/src/terminal.rs
@@ -178,9 +178,9 @@
             ApplicationKeypadModeEnable => write(self, b"\x1b="),
             ApplicationKeypadModeDisable => write(self, b"\x1b>"),
             Osc0WindowTitle(title) => osc_0_window_title(self, title),
-            Osc133PromptStart => write(self, OSC_133_PROMPT_START),
-            Osc133CommandStart(command) => osc_133_command_start(self, command),
-            Osc133CommandFinished(s) => osc_133_command_finished(self, s),
+            Osc133PromptStart => false,
+            Osc133CommandStart(_command) => false,
+            Osc133CommandFinished(s) => false,
             QueryCursorPosition => write(self, b"\x1b[6n"),
             ScrollForward(lines) => scroll_forward(self, lines),
             DecsetShowCursor => write(self, b"\x1b[?25h"),

[nonkr]

@krobelus thanks, it works.

Just a little other words before greeting, does not affect use.

[krobelus]

Both issues should be easy to fix in WindTerm.
Maybe we should work around it.. but that's only easy if the terminal exports a unique $TERM value.

[farmergreg]

I'm running into this on Debian Trixie Proxmox VMs with their display set to a serial port. Perhaps a setting should be created to allows users to disable OSC 133 sequences in their config or extend no-keyboard-protocols to disable osc 133 sequences?

[krobelus]

we could definitely add an option to disable OSC 133 output, but I'd
like to understand the use case, and how the option would help you (I assume it's different from WindTerm scenario).

An interactive fish, will print escape sequences to stdout -- even if stdout is not a TTY:

$ fish -C 'fish_prompt' | string escape
\e\[32m\~\e\[m\e\[m\>\ \e\]7\;file://myhostname/home/johannes\cg\e\]0\;\~\cg\e\[m\r\e\]133\;A\;click_events=1\cg\e\[32m\~\e\[m\e\[m\>\ \e\[J\r\e\[3C\e\[?2004h\e\[?2004l\e\]0\;\~\cg\e\[m\r\e\]133\;A\;click_events=1\cg\$\ \e\[K\r\e\[2C
\e\[m\e\[m⏎ 

Is the problem that your serial port read end doesn't parse OSC sequences (the ones starting with \e]). How does it deal with CSI sequences (\e[...) then
which are used for cursor movement, colors, bracketed paste etc.? There's also \r and \n

If it helps, we can add this to disable OSC 133 markers:

set fish_prompt_marking_enabled false

We can mention that in terminal-compatibility.rst.

[farmergreg]

Thanks @krobelus for your questions.
I'm not deeply knowledgeable on the details of osc and escape sequences, but here is what i see with a default fish configuration:

I tried changing the prompt to be "simple" by doing this:
function fish_prompt
echo -n '> '
end

when I login with that, I see:

... and for completeness, I ran (with the simplified prompt):
set -Ua fish_features no-keyboard-protocols which results in this

I should also mention that these screen shots are with fish 4.0.2 (apt install fish in Debian Trixie). I tried by building master earlier today, and had similar results.

[krobelus]

Linux supports OSC sequences since 63f3a16db915 (vt: detect and ignore OSC codes., 2014-02-19).
Debian Trixie ships Linux 4.12 (?) according to https://packages.debian.org/search?keywords=linux

That version should have OSC support; tested by running
git merge-base --is-ancestor 63f3a16db915 v4.12

Is there a way I can reproduce this, e.g. by running a Debian Trixie image in qemu?
I'm trying to figure out which component needs to be fixed.

[farmergreg]

The VM is running Linux 6.12.38+deb13-cloud-amd64. I'm not sure if I understand correctly. Should Linux be removing the characters when it detects a serial console (e.g. ttyS0)? Or could the bug be in the Proxmox terminal that is receiving the output from the serial port?

Do you have access to a Proxmox install? If you do have access, I have the scripts that I am using to create the VM on proxmox. The script is small and I could send them to you.

If you don't have easy access to a Proxmox installation, i could set one up for testing and give you access via tailscale.

[krobelus]

On Fri, Jul 25, 2025 at 12:22:05PM -0700, Greg Dietsche wrote: farmergreg left a comment (fish-shell/fish-shell#11609) The VM is running Linux 6.12.38+deb13-cloud-amd64. I'm not sure if I understand correctly. Should Linux be removing the characters when it detects a serial console (e.g. ttyS0)? Or could the bug be in the Proxmox terminal that is receiving the output from the serial port?

Oh well if fish outputs to a serial port instead of to the Linux Console, then it is most likely an issue in the terminal that is connected to the serial port. That terminal is supposed to silently consume CSI and OSC sequences; (the TTY driver in Linux should forward almost everything as-is, it only handles things like ctrl-c/ctrl-s (VINTR/VSUSP) etc) We should find out which terminal is used here, ideally find the source code, and how to compile and run it. Then I could fix it easily. I looked at sources for these two; both already seem to parse OSC sequences (though there's a buffer overflow at 4k characters..) - https://git.proxmox.com/?p=vncterm.git;a=summary - https://git.proxmox.com/?p=spiceterm.git;a=summary

Do you have access to a Proxmox install? If you do have access, I have the scripts that I am using to create the VM on proxmox. The script is small and I could send them to you. If you don't have easy access to a Proxmox installation, i could set one up for testing and give you access via tailscale.

yeah that might help if we're still struggling. I haven't used Proxmox before; to reproduce this bug we should not need a VM or anything. The Proxmox terminal running bash (or fish etc) should be enough. In that shell, commands like this one should output nothing printf '\x1b]133;A;click_events=1\x07'

[krobelus]

ah I missed pve-xtermjs (in case the terminal is running in a JS environment)

[krobelus]

xterm.js definitely supports OSC sequences (tested with the snnippet below),
and Proxmox is at the latest xterm.js version.. strange..

<!doctype html>
  <html>
    <head>
      <link rel="stylesheet" href="node_modules/@xterm/xterm/css/xterm.css" />
      <script src="node_modules/@xterm/xterm/lib/xterm.js"></script>
    </head>
    <body>
      <div id="terminal"></div>
      <script>
        var term = new Terminal();
        term.open(document.getElementById('terminal'));
        term.write('Hello from \x1B[1;3;31mxterm.js\x1B[0m $\n')
        term.write('OSC command (should render as <>): <\x1b]133;A;click_events=1\x07> ')
      </script>
    </body>
  </html>
```

[farmergreg]

For what it is worth, I can see that Proxmox is using a web socket, and appears to be using noVNC to display the console. This doesn't necessary rule out xterm.js, but it is what i see in the Network tab of the debug tools in my browser.