fix(desktop): drain command output concurrently to avoid Process deadlock

ProcessCommandExecutor called waitUntilExit() before reading either
pipe. Once combined stdout+stderr exceeds the ~64KB pipe buffer, the
child blocks on write() with nothing draining it, so it never exits
and the continuation never resumes.

TerminalWrapperDetector's `ps -Ao pid=,command=` call is the first
caller whose output realistically exceeds that buffer (174KB on a
typical dev machine with the browser and other apps running), so this
deadlocked SessionManager.refresh() on every launch — the app never
left its "Loading..." state. Read both pipes on background queues
while the process runs, then wait for exit.

Verified the regression reproduces without the fix: swift test itself
hung past the 2-minute harness timeout and had to be force-killed, not
just the individual test case.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

Author: grokify

apps/desktop/Sources/PlexusOneDesktop/Services/CommandExecuting.swift

@@ -20,10 +20,27 @@ struct ProcessCommandExecutor: CommandExecuting {
 
             do {
                 try process.run()
-                process.waitUntilExit()
 
-                let stdoutData = stdoutPipe.fileHandleForReading.readDataToEndOfFile()
-                let stderrData = stderrPipe.fileHandleForReading.readDataToEndOfFile()
+                // Drain both pipes concurrently with the process running. Reading
+                // only after waitUntilExit() deadlocks once combined output
+                // exceeds the pipe buffer (~64KB): the child blocks on write()
+                // with nothing reading, so it never exits.
+                var stdoutData = Data()
+                var stderrData = Data()
+                let readGroup = DispatchGroup()
+
+                readGroup.enter()
+                DispatchQueue.global(qos: .utility).async {
+                    stdoutData = stdoutPipe.fileHandleForReading.readDataToEndOfFile()
+                    readGroup.leave()
+                }
+                readGroup.enter()
+                DispatchQueue.global(qos: .utility).async {
+                    stderrData = stderrPipe.fileHandleForReading.readDataToEndOfFile()
+                    readGroup.leave()
+                }
+                readGroup.wait()
+                process.waitUntilExit()
 
                 let result = CommandResult(
                     exitCode: process.terminationStatus,

apps/desktop/Tests/PlexusOneDesktopTests/CommandExecutingTests.swift

@@ -0,0 +1,47 @@
+import XCTest
+@testable import PlexusOneDesktop
+
+final class CommandExecutingTests: XCTestCase {
+
+    /// `ps -Ao pid=,command=` on a typical dev machine easily exceeds the ~64KB
+    /// pipe buffer. Reading stdout only after waitUntilExit() deadlocks in that
+    /// case: the child blocks on write() with nothing draining the pipe, so it
+    /// never exits and the continuation never resumes.
+    func testExecuteHandlesOutputLargerThanPipeBuffer() async throws {
+        let executor = ProcessCommandExecutor()
+
+        // Print well over 64KB to stdout, interleaved with some stderr output,
+        // to exercise both pipes concurrently.
+        let script = """
+        for i in $(seq 1 20000); do echo "line $i of padding output to exceed the pipe buffer"; done
+        echo "some stderr output" >&2
+        """
+
+        let result = try await withTimeout(seconds: 10) {
+            try await executor.execute("/bin/sh", arguments: ["-c", script])
+        }
+
+        XCTAssertEqual(result.exitCode, 0)
+        XCTAssertGreaterThan(result.stdout.utf8.count, 64 * 1024)
+        XCTAssertTrue(result.stdout.contains("line 20000 of padding"))
+        XCTAssertTrue(result.stderr.contains("some stderr output"))
+    }
+
+    private func withTimeout<T: Sendable>(
+        seconds: TimeInterval,
+        _ operation: @escaping @Sendable () async throws -> T
+    ) async throws -> T {
+        try await withThrowingTaskGroup(of: T.self) { group in
+            group.addTask { try await operation() }
+            group.addTask {
+                try await Task.sleep(nanoseconds: UInt64(seconds * 1_000_000_000))
+                throw TimeoutError()
+            }
+            let result = try await group.next()!
+            group.cancelAll()
+            return result
+        }
+    }
+
+    private struct TimeoutError: Error {}
+}