[BUG] Command Mode can hang far past its timeout when a command leaves a background descendant holding stdout or stderr

[postoso]

Describe the bug

TerminalService.execute reads command output with readDataToEndOfFile() after waitUntilExit() (Sources/Fluid/Services/TerminalService.swift:111-115). That read ends at EOF, and EOF arrives only when every process holding the write end has closed it. A command that leaves a background descendant behind keeps the pipe open after /bin/zsh exits, so the read blocks.

The timeout argument does not bound this. The timeout task calls process.terminate() only while process.isRunning, and by the time the read starts the shell has already exited.

Reproduction steps

1. Run a Command Mode command that backgrounds something outliving the shell, for example ( sleep 60 & ) ; echo started.
2. Wait past the configured timeout.

Measured with a standalone Swift program mirroring that code shape rather than through the UI: /bin/zsh -c "( sleep 60 & ) ; echo started", both pipes, waitUntilExit() then readDataToEndOfFile().

waitUntilExit returned : 0.068 s  (exit 0, isRunning=false)
stdout read returned   : 60.010 s
stderr read returned   : 60.010 s
stdout                 : "started" (8 bytes)

Expected behavior

execute returns within its timeout with whatever output has arrived.

Actual behavior

execute returns only when the descendant closes the pipe. The output was complete at 0.07 s and handed back at 60 s.

App Version

1.6.9. Sources/Fluid/Services/TerminalService.swift is identical at tag v1.6.9 and on main (66ca682).

macOS Version

macOS 15.7.7 (24G720)

Architecture

Apple Silicon

Additional context

Two things I found trying to fix this on #430. Both were measured on that patched branch, not on main, so they are notes on the fix rather than on current behaviour.

Bounding each drain by the caller's timeout does fix the return, 60.834 s down to 2.004 s on a 2 second timeout. Polling the descriptor first is not enough on its own though: FileHandle.read(upToCount:) keeps reading until it has the full requested count or hits EOF, so it blocks past the deadline anyway and needs a plain read(2) after the poll.

That still leaves the descendant alive. process.terminate() signals the shell, not its children, so the writer survives and blocks on a write nobody drains. Locally that left a yes writer running for minutes after execute had returned. Launching the command in its own process group and signalling the group looks like the real fix, and it changes how TerminalService starts processes, which is why I did not fold it into #430.

[altic-dev]

Yeah, I know there are problems with terminals and background processing which I was supposed to fix, but I did not because I was focusing more on dictation. We can put this on a hold, maybe move it to a discussion or something so you can come back to this a little later.

Or if you think you can patch it up in a minimal way without affecting anything else, I'm down for your fix. If #430 is the fix that you're talking about, then we can look into it, whatever you want.

[postoso]

Thanks. These are two different problems, so my suggestion is to split them.

The pipe-buffer deadlock (a command printing more than 64 KB blocks forever) is what #430 fixes: drain both pipes while the command runs, keep at most 1 MiB per stream, and note when output was truncated. That is all #430 contains. The timeout-bounded reads I described above were never pushed, so it is the minimal change and it does not touch anything else. If you are fine taking it as is, it is ready.

This issue is the other problem: a background descendant keeps the pipe open past the timeout, and terminate() only reaches the shell. The real fix is launching each command in its own process group and signalling the group, which changes how TerminalService starts processes. I would rather bring that as its own PR when you are ready for it than fold it into #430. Happy to keep this issue open until then, or move it to a discussion if you prefer.