bug: sandbox detach fails with Kitty keyboard protocol and leaks terminal state
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 32/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- rust
- 領域
- cli, operating-systems
調査の方向性
まず、Kitty/CSI-u 対応端末でドキュメント化された detach ワークフローを再現し、次に関連する作業 #2710 および #2726 で説明されている、保持されたセッションと detach の動作を追跡します。完了の条件は、detach 入力がアプリケーションに渡されないこと、ローカル端末を引き続き使用できること、再接続によって実行中のプロセスと入力モードが保持されること、従来の入力も引き続き機能すること、そしてリグレッションカバレッジとドキュメントが両方の経路を対象としていることです。
索引モデルが issue の本文から書いたものです。
説明
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.
- 主要言語
- Rust
- スター
- 8.7k
- フォーク
- 1.3k
- 平均マージ
- 2日 6時間
- マージ済み PR(30日)
- 297
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
NVIDIA/OpenShell のほかの issue
-
area:docs
難易度 1/5 1時間未満 初心者へのやさしさ 88/100
-
state:triage-needed
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
-
area:cli state:validated
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
-
state:triage-needed
難易度 1/5 1時間未満 初心者へのやさしさ 90/100
-
area:build spike state:review-ready state:stale
難易度 2/5 半日 初心者へのやさしさ 68/100
NVIDIA/OpenShell の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
-
state:needs triage
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
zed-industries/zed#64680 · コメント 2 件 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 70/100
RustPython/RustPython#8802 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
TheLarkInn/aipm#2390 ·