bug: sandbox detach fails with Kitty keyboard protocol and leaks terminal state
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 32/100
- Loại issue
- Lỗi
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- rust
- Lĩnh vực
- cli, operating-systems
Hướng nghiên cứu
Bắt đầu bằng cách tái hiện workflow detach đã được ghi lại bằng một terminal hỗ trợ Kitty/CSI-u, sau đó theo dõi hành vi của phiên được giữ lại và detach được mô tả trong các công việc liên quan #2710 và #2726. Được xem là hoàn tất khi đầu vào detach không được chuyển đến ứng dụng, terminal cục bộ vẫn có thể sử dụng, việc kết nối lại bảo toàn tiến trình đang chạy và chế độ đầu vào, đầu vào truyền thống vẫn hoạt động, đồng thời phạm vi kiểm thử hồi quy và tài liệu bao quát cả hai đường đi.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
User Story
As a user running an interactive terminal application in a reconnectable sandbox, I want to disconnect without terminating the application, so that I can safely return to my local shell and reconnect to the same live session later.
Problem Statement
The documented Ctrl-P, then Ctrl-Q sandbox detach sequence does not work when the attached application enables the Kitty keyboard protocol (CSI-u keyboard encoding).
In this state, pressing Ctrl-P is observed by the attached application instead of initiating OpenShell's detach sequence. The application may handle it as one of its own shortcuts, and the connection remains attached.
Using the SSH transport's escape mechanism as a fallback closes the connection, but the local terminal can remain in the extended keyboard mode enabled by the still-running remote application. After control returns to the local shell, normal keystrokes appear as CSI-u fragments and control or navigation keys no longer behave normally.
The application remains alive by design, so it does not run its normal terminal cleanup. A subsequent reconnect must also leave the terminal and application in compatible input modes without restarting the application.
Impact / Why This Matters
This blocks the intended reconnectable-session workflow for interactive terminal applications that use modern keyboard protocols. Pi is one known reproducer, but the behavior is not specific to a particular agent or application.
Users currently have to either terminate the application cleanly, losing the live session they intended to preserve, or forcibly disconnect and then manually reset or reopen their local terminal. The detach keystroke can also trigger an unintended application action because it is delivered to the remote process.
These workarounds defeat the purpose of a persistent, reconnectable main process and make it unsafe or disruptive to leave an interactive session running.
Acceptance Criteria
- The documented detach workflow succeeds while the attached application has enabled the Kitty keyboard protocol.
- Input used to request detach is not delivered to the attached application.
- Detaching does not terminate, suspend, send EOF to, or otherwise disrupt the sandbox's canonical main process.
- Returning from the attachment leaves the local shell in a usable terminal state without visible CSI-u fragments or broken control and navigation keys.
- Reconnecting attaches to the same running process and provides the keyboard/input mode expected by the application without requiring an application restart.
- Detach continues to work with terminals and applications that use traditional control-byte input.
- Published documentation describes the supported detach behavior for interactive, reconnectable sessions.
- Regression coverage exercises both traditional control-byte input and Kitty-encoded input where practical.
Reproduction Steps
- From a CSI-u-capable terminal, start a reconnectable sandbox whose retained main process is an interactive terminal application that enables the Kitty keyboard protocol.
- Attach to the retained process and confirm that the application is interactive.
- Press OpenShell's documented detach sequence.
- Observe that the first keystroke is handled by the application and the session remains attached.
- Disconnect using the SSH transport's escape mechanism so that the remote application remains running.
- At the restored local shell prompt, type normally.
- Observe CSI-u fragments in the input or incorrectly behaving control and navigation keys.
Environment
- OpenShell: observed with a recent Homebrew installation; exact affected version was not captured
- Latest release checked before filing: v0.0.116
- OS: macOS
- Host shell: zsh
- Runtime: local Homebrew gateway with a Docker-backed sandbox
- Integration: interactive TUI that enables the Kitty keyboard protocol; Pi is a known reproducer
- Terminal: CSI-u-capable terminal; exact emulator and version were not captured
Logs
08;5:1u08;5:3u7;5:
The excerpt is representative text appearing at the local shell prompt after disconnecting. No credentials or request data are included.
Related Work
- #2710 defines the reconnectable canonical-main-process behavior.
- #2726 implements retained sessions and detach behavior.
- #2392 discusses terminal-state pollution after returning from an interactive sandbox shell.
- earendil-works/pi#5724 reports terminal corruption when Kitty keyboard mode is not disabled during cleanup.
- earendil-works/pi#1204 describes Kitty keyboard events leaking across an SSH session.
- earendil-works/pi#3918 reports CSI-u input reaching the parent shell when terminal cleanup does not run.
- Ngôn ngữ chính
- Rust
- Star
- 8.7k
- Fork
- 1.3k
- Merge trung bình
- 2 ngày 6 giờ
- Pull request đã merge (30 ngày)
- 297
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của NVIDIA/OpenShell
-
area:docs
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
-
state:triage-needed
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
-
area:cli state:validated
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
-
state:triage-needed
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 90/100
-
area:build spike state:review-ready state:stale
Độ khó 2/5 Nửa ngày Mức phù hợp với người mới 68/100
Tất cả issue của NVIDIA/OpenShell
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
-
state:needs triage
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
zed-industries/zed#64680 · 2 bình luận ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
RustPython/RustPython#8802 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
TheLarkInn/aipm#2390 ·