Shell sessions running lazydocker over SSH become unusable after losing the SSH connection

[zheng]

Dupe Check

• I have searched Warp bugs and there are no duplicates

Describe the bug

Whenever the SSH session disconnects (e.g. when my laptop sleeps), I get these escape sequences that spam the session and I can never recover the session. I need to close the pane and then create a new one

To reproduce

I haven't invested in reproducing this situation. If there's appetite to fix this, I'm happy to try and create a VM, or screen share to debug this

Expected behavior

No response

Screenshots

No response

Operating system

MacOS

Operating system and version

Sonoma 14.3

Shell Version

No response

Current Warp version

No response

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

No response

Does this block you from using Warp daily?

Yes, this issue prevents me from using Warp daily.

Is this a Warp specific issue? (i.e. does it happen in Terminal, iTerm, Kitty, etc.)

Yes, this I confirmed this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[alokedesai]

Miss you Zheng!

[zheng]

Miss you too!

By the way, the subshell bootstrapping works incredibly well. The team did an incredible job on that. I've been SSH-ing every session and I'm amazed at how well it works

[alokedesai]

We're actively working on a set of a improvements to improve SSH, including these SSH hangup issues. Should have an update in the next few weeks and we may reach out if we need any help reproducing (if that's ok with you!)

[zheng]

We're actively working on a set of a improvements to improve SSH, including these SSH hangup issues. Should have an update in the next few weeks and we may reach out if we need any help reproducing (if that's ok with you!)

Yes, please reach out if I can be helpful for this or any other ssh issues!

[vorporeal]

I believe I have a fix for this!

@zheng As a quick test, can you reproduce this state, and then:

1. Press ctrl+u to clear anything in the input buffer
2. Run vim
3. Quit vim

and let me know if that gets you back into a good state?

I believe the issue here is that we're not forcibly exiting the alt screen when we get a notification from the shell that a command finished (and ssh isn't sending us any escape sequence to exit the alt screen either). We end up stuck in the alt screen (fixed by running and quitting vim), and so control sequences that are intended to be consumed by alt screen programs (e.g.: telling a TUI program about mouse movements) are actually getting inserted into the shell's line editor.

Will have a fix out in next week's release. :)

[vorporeal]

Reopening this until it goes live (but the fix is merged).

[zheng]

I believe I have a fix for this!

@zheng As a quick test, can you reproduce this state, and then:

1. Press ctrl+u to clear anything in the input buffer
2. Run vim
3. Quit vim

and let me know if that gets you back into a good state?

I believe the issue here is that we're not forcibly exiting the alt screen when we get a notification from the shell that a command finished (and ssh isn't sending us any escape sequence to exit the alt screen either). We end up stuck in the alt screen (fixed by running and quitting vim), and so control sequences that are intended to be consumed by alt screen programs (e.g.: telling a TUI program about mouse movements) are actually getting inserted into the shell's line editor.

Will have a fix out in next week's release. :)

I've opened a SSH session to reproduce this state, should be able to try out this fix in the next few hours!

[alokedesai]

@zheng Thank you! The easiest way we reproduced was by temporarily turning off wifi (in case it helps you repro more reliably)

[zheng]

The fix works!