SSH session terminates with Arg_IndexOutOfRangeException in Terminal.ExecuteCommand during ParseXtermData

SSH session terminates with Arg_IndexOutOfRangeException in Terminal.ExecuteCommand during ParseXtermData

avatar

Version: RDM macOS 2026.1.12.2, Devolutions.ProtocolsSharp 2026.4.17.1
Server: OpenSSH 8.9p1 Ubuntu 22.04, xterm-256color
Behavior: Session establishes successfully, runs for varying duration (seconds to minutes), then unexpectedly terminates with the above exception. Server logs show clean Received disconnect: Logout (client-side disconnect). Log excerpt attached.
Stack:
DoShellLoopAsync: Arg_IndexOutOfRangeException
at Devolutions.Protocols.Core.Terminal.ExecuteCommand(ReadOnlySpan`1 data)
at Devolutions.Protocols.Core.Terminal.ParseXtermData(ReadOnlySpan`1 data)
at Devolutions.Protocols.Core.SshClient.DoShellLoopAsync(Channel channel, Upper upper)

ssh.log.zip

All Comments (6)

avatar

Hello,

Thank you for the details and log excerpt.

The logs suggest a possible terminal parsing issue in RDM for macOS / Devolutions.ProtocolsSharp, likely triggered by terminal output, an xterm/ANSI escape sequence, the shell prompt, or startup scripts.

Could you please try changing the terminal type from `xterm-256color` to `xterm` or `vt100` and test again?

You can find this setting in RDM under **File → Settings → Types → Terminal**.

Could you also send us a screenshot of the **Local** section in that Terminal settings page?

We will review this as a possible issue with the terminal parser.

Best regards,

Carl Marien

avatar

Hello,

Thank you for the suggestion. I tried both xterm and vt100 as terminal types - the issue persists, the crash is identical. Logs from the vt100 test are attached.

For reference: rolling back to the previous RDM version resolves the problem entirely, which points to a regression in the current Devolutions.ProtocolsSharp terminal parser.

Also attached: screenshot of the Local section under Terminal settings (I haven't modified anything there myself):

858c005d-d66d-407e-b4b3-754a9d5a2774

Let me know if you need any additional logs or details.

Best regards

858c005d-d66d-407e-b4b3-754a9d5a2774.png

ssh-vt100.log.zip

avatar

Hello,

Thank you for the additional logs and the screenshot.

Based on your Terminal settings, a TERM environment variable is currently set to xterm-256color under File > Settings > Types > Terminal > Local. This environment variable overrides the terminal type selected in RDM, which explains why switching to xterm or vt100 did not change the behavior.

Could you please remove the TERM entry from the environment variables list and test again?

That said, since rolling back to the previous version resolves the issue, we will flag this as a regression on our end. I will wait for your response before opening the case internally.

Best regards,

Carl Marien

avatar

Hi,

I've removed TERM variable and set default to vt100.
Same behavior:

[25.05.2026 20:42:16] Received data request: 42 bytes 0|0
[25.05.2026 20:42:16] Received data request: 28 bytes 0|0
[25.05.2026 20:42:16] Sending window adjust: 1014 0|0
[25.05.2026 20:42:16] DoShellLoopAsync: Arg_IndexOutOfRangeException
[25.05.2026 20:42:16] at Devolutions.Protocols.Core.Terminal.ExecuteCommand(ReadOnlySpan`1 data)
at Devolutions.Protocols.Core.Terminal.ParseXtermData(ReadOnlySpan`1 data)
at Devolutions.Protocols.Core.Terminal.ParseData(ReadOnlySpan`1 data)
at Devolutions.Protocols.Core.SshClient.DoShellLoopAsync(Channel channel, Upper upper)
[25.05.2026 20:42:16] Sending channel close request: 0|0
[25.05.2026 20:42:16] Disconnection in progress
[25.05.2026 20:42:16] Sending disconnect request

It's so strange because it happens only to one host. Other seems to be fine. It's vt100 now for 100%, Midnight Commander is in B&W.

avatar

Hello,

I have isolated the root cause.

The server had iTerm2 shell integration installed in ~/.profile (sourcing ~/.iterm2_shell_integration.bash). This script adds special escape sequences (OSC 1337 and OSC 133) to the prompt. They are sent every time the prompt is drawn.

RDM crashes when it receives these sequences - that is the IndexOutOfRangeException in ParseXtermData from my earlier logs.

On my side I removed the iTerm2 integration and sessions are stable now. But the parser should ignore unknown sequences instead of crashing.

avatar

Hi,

Thank you for the detailed report.
A ticket has been created for the issue, and our Protocol team is currently investigating and working on a fix.
We’ll keep you updated as soon as the issue is resolved.
We’re sorry for the inconvenience caused.

Best regards,

Jesse Galarneau