Repository navigation
Closed
Labels
state:acceptedA maintainer decided OpenShell should pursue this issueA maintainer decided OpenShell should pursue this issue
Description
Agent Diagnostic
- Skills loaded: create-github-issue, openshell-cli
- OpenShell version tested: 0.0.101
- Latest release checked: unable to verify (testing against dev build)
- Known fixes reviewed: unable to verify
- Possible duplicates reviewed: searched "sandbox allocated progress repeat" and "sandbox create progress display", no results
- Findings: The CLI's
sandbox createprogress renderer emits a new line for every gRPC status poll response instead of updating in-place. During image pull (which can take 30-60s), the status stays at "Sandbox allocated" while the container runtime pulls the image, producing dozens to hundreds of identical lines. - Remaining reason for filing: The output floods the terminal and obscures the actual progress information.
Description
Actual behavior: When creating a sandbox with a large or uncached container image, openshell sandbox create prints "Sandbox allocated (0s)" on a new line for every status poll iteration while the image is being pulled. This produces 30-100+ identical lines depending on pull duration:
✓ Sandbox allocated (0s)
✓ Sandbox allocated (0s)
✓ Sandbox allocated (0s)
✓ Sandbox allocated (0s)
... (repeats dozens of times)
✓ Image already present
✓ Starting sandbox
Expected behavior: The progress display should either:
- Update the current line in-place (overwrite with
\ror terminal cursor control) when the status hasn't changed, or - Deduplicate consecutive identical status messages and only print when the phase or message text changes, or
- Show a spinner/progress indicator for long-running phases like image pull
Reproduction Steps
- Create a sandbox using an image that isn't cached in the container runtime:
openshell sandbox create --name test \ --from <large-uncached-image>:latest \ --no-tty -- sh -c "echo ready"
- Observe the terminal output during image pull
The issue is most visible with the Docker compute driver inside SAW VMs where image pulls go through the internal OpenShift registry. Images cached locally produce only 1-2 lines (no delay between allocation and start).
Environment
- OS: macOS (client), Fedora 44 (VM/sandbox host)
- Compute driver: Docker (inside SAW VM on OpenShift Virtualization)
- OpenShell CLI: 0.0.101
- Gateway: 0.0.102-dev.4
- Latest release checked: no
- Possible duplicates checked: yes, none found
Metadata
Metadata
Assignees
Labels
state:acceptedA maintainer decided OpenShell should pursue this issueA maintainer decided OpenShell should pursue this issue
Activity
letv1nnn commentedon Aug 10, 2026
Hey @rhuss, I think I hit this in #2655 too, screenshot there shows
Sandbox allocated (0s)twice on a quick provision, no large/uncached image. So it's probably not pull-specific, it happens any time that step takes a bit longer, because the server sends the same progress update more than once.franciscojavierarceo commentedon Aug 18, 2026
📋 triage-agent
Triage Assessment
Classification: validated-bug
Summary
The report is confirmed. Repeated provisioning completion events are deduplicated in the interactive display, but plain/non-interactive output prints a line for every repeated event. This matches the reported
--no-ttybehavior.Investigation
crates/openshell-cli/src/commands/common.rsmaps the requesting-sandbox completion event toSandbox allocated.ProvisioningDisplaydeduplicates completed steps.println!for every completion event and has no deduplication.Impact Signals
Human Decision Status
This issue is already labeled
state:accepted. No acceptance or intake-state label was changed. The likely fix is to deduplicate consecutive completion events in plain output, with regression coverage for repeated identical events.krishicks commentedon Aug 27, 2026
Fixed by #2816