User Story
As a developer attached to a long-running sandbox, I want transport recovery to resume from the output I last received, so that a brief interruption does not flood my terminal with duplicate history.
Problem Statement
Each canonical-main SSH attachment subscribes at the oldest event still held in the supervisor output buffer. PR #3573 adds automatic SSH reattachment after transport loss, so every recovery attempt can replay up to 1 MiB of already displayed output. Multiple attempts on a flaky connection repeat that history each time.
Impact / Why This Matters
Duplicate output obscures the point where the interruption occurred, fills terminal scrollback, and makes logs appear to contain events that happened more than once. Manually finding the new-output boundary is unreliable, especially for verbose workloads. Disabling recovery avoids duplication but gives up transparent sleep and wake recovery.
Acceptance Criteria
Reproduction Steps
- Create a persistent sandbox whose canonical main process emits enough output to populate retained history.
- Run
openshell sandbox connect and observe the output.
- Interrupt the established SSH transport so automatic recovery starts.
- Observe that the replacement attachment replays retained output that the terminal already displayed.
- Repeat the interruption and observe the same history again.
Environment
Context
Follow-up to #3573 and #3638. A complete solution likely needs a logical attachment cursor or equivalent resume position rather than changing fresh-attachment replay semantics.
User Story
As a developer attached to a long-running sandbox, I want transport recovery to resume from the output I last received, so that a brief interruption does not flood my terminal with duplicate history.
Problem Statement
Each canonical-main SSH attachment subscribes at the oldest event still held in the supervisor output buffer. PR #3573 adds automatic SSH reattachment after transport loss, so every recovery attempt can replay up to 1 MiB of already displayed output. Multiple attempts on a flaky connection repeat that history each time.
Impact / Why This Matters
Duplicate output obscures the point where the interruption occurred, fills terminal scrollback, and makes logs appear to contain events that happened more than once. Manually finding the new-output boundary is unreliable, especially for verbose workloads. Disabling recovery avoids duplication but gives up transparent sleep and wake recovery.
Acceptance Criteria
Reproduction Steps
openshell sandbox connectand observe the output.Environment
Context
Follow-up to #3573 and #3638. A complete solution likely needs a logical attachment cursor or equivalent resume position rather than changing fresh-attachment replay semantics.