Shell tool appears stuck when a completed git push output is not surfaced promptly

1|# Codex #24526: Shell Tool Appears Stuck When git push Output Not Surfaced Promptly
2|
3|## Issue Summary
4|
5|A git push command appeared to hang for several minutes even though it completed successfully. The UI showed the command as still running, but when polled later, the push output appeared immediately with successful results.
6|
7|## Root Cause Analysis
8|
9|The shell tool's output streaming/polling mechanism doesn't properly surface completed command output. The process completes but the UI doesn't detect completion, leaving the command appearing "stuck" until a manual poll triggers output retrieval.
10|
11|## Proposed Fix
12|
13|### Fix 1: Improve Process Completion Detection
14|
15|``typescript
16|class ShellTool {
17| async execute(command: string): Promise<ShellResult> {
18| const proc = spawn(command, { shell: true });
19|
20| let output = '';
21| let completed = false;
22|
23| // Stream output in real-time
24| proc.stdout.on('data', (data) => {
25| output += data.toString();
26| this.ui.updateOutput(output); // Real-time UI update
27| });
28|
29| proc.stderr.on('data', (data) => {
30| output += data.toString();
31| this.ui.updateOutput(output);
32| });
33|
34| // Detect completion immediately
35| proc.on('close', (code) => {
36| completed = true;
37| this.ui.markComplete(code);
38| });
39|
40| // Don't wait for poll — resolve when process actually completes
41| return new Promise((resolve) => {
42| const checkComplete = () => {
43| if (completed) {
44| resolve({ output, exitCode: proc.exitCode });
45| } else {
46| setTimeout(checkComplete, 100);
47| }
48| };
49| checkComplete();
50| });
51| }
52|}
53|`
54|
55|### Fix 2: Add Progress Indicators for Long-Running Commands
56|
57|`typescript
58|// For commands that take >30 seconds, show progress
59|if (estimatedDuration > 30000) {
60| this.ui.showProgress({
61| command,
62| elapsed: Date.now() - startTime,
63| status: 'running',
64| outputPreview: output.slice(-200)
65| });
66|}
67|``
68|
69|## Impact
70|
71|- UX: MEDIUM — Users confused about whether command is stuck
72|- Scope: Low — Affects git push and similar network commands
73|- Fix complexity: LOW — Output streaming improvement, ~80 lines
74|

Solution: Fix Shell Tool Output Streaming

Root Cause

The shell tool's output streaming mechanism doesn't promptly deliver completion signals and output to the UI. The git push command completes successfully, but the UI shows it as "stuck" because output may be buffered instead of streamed immediately, and stream close detection may not properly wait for all output to be consumed.

Fix

Three-part fix:

1. Immediate output streaming: Stream stdout/stderr to UI as data arrives, not at completion
2. Proper stream close detection: Wait for both stdout 'end' and stderr 'end' events before signaling completion
3. setImmediate flush: Use setImmediate to ensure all buffered output is flushed before resolving

proc.stdout.on('data', (chunk) => streamToUI({ type: 'stdout', data: chunk }));
proc.stdout.on('end', () => { outputComplete.stdout = true; checkDone(); });
proc.on('close', (code) => { exitCode = code; checkDone(); });

function checkDone() {
    if (outputComplete.stdout && outputComplete.stderr && exitCode !== null) {
        setImmediate(() => resolve({ stdout, stderr, exitCode }));
    }
}

Why This Works

• Real-time output: Users see output as it's produced
• Accurate completion: Only resolves after all output is consumed
• Buffer flush: setImmediate ensures no buffered output is lost

## Solution: Fix Shell Tool Output Streaming ### Root Cause The shell tool's output streaming mechanism doesn't promptly deliver completion signals and output to the UI. The git push command completes successfully, but the UI shows it as "stuck" because output may be buffered instead of streamed immediately, and stream close detection may not properly wait for all output to be consumed. ### Fix Three-part fix: 1. Immediate output streaming: Stream stdout/stderr to UI as data arrives, not at completion 2. Proper stream close detection: Wait for both stdout 'end' and stderr 'end' events before signaling completion 3. setImmediate flush: Use setImmediate to ensure all buffered output is flushed before resolving proc.stdout.on('data', (chunk) => streamToUI({ type: 'stdout', data: chunk })); proc.stdout.on('end', () => { outputComplete.stdout = true; checkDone(); }); proc.on('close', (code) => { exitCode = code; checkDone(); }); function checkDone() { if (outputComplete.stdout && outputComplete.stderr && exitCode !== null) { setImmediate(() => resolve({ stdout, stderr, exitCode })); } } ### Why This Works Real-time output: Users see output as it's produced Accurate completion: Only resolves after all output is consumed * Buffer flush: setImmediate ensures no buffered output is lost

Thanks for writing this up. I checked the current implementation and I think the relevant path is a bit different:
I checked current main (8a94430b) and this seems slightly different from a simple stdout/stderr streaming bug.

The current implementation is Rust, and unified exec already starts background output streaming plus an exit watcher. What I can reproduce is the model-facing polling behavior:

1. Run sh -c 'sleep 2; printf done' with yield_time_ms=500
2. Initial exec_command returns a running session with no output
3. Wait >2s
4. Poll with empty write_stdin
5. The final output appears immediately

So completed output can remain pending until a later poll for the tool-response path. But the UI should still receive ExecCommandEnd from the background watcher. If the visible
UI remains “running”, the likely issue is event delivery/rendering or hosted wrapper state, not basic process completion detection.

Approval seems like a separate state boundary: approval happens before process spawn; a running session means approval already completed.