[Bug]: [Windows] Foreground npm run dev blocks the agent and Stop leaves the task aborted without recovery

[mauryaankur99]

Summary

On Windows, when an OpenWork agent runs a persistent development server such as npm run dev as a foreground command, the server starts successfully but the command remains in the Running state because the server does not terminate and keeps stdout/stderr open.

OpenWork then waits for the command to finish and does not proceed to HTTP or browser testing. The only visible way to continue is to manually click Stop, but this marks the operation as `Aborted` and the agent does not reliably resume the unfinished work.

The development server itself may already be working correctly on localhost. The problem is that OpenWork treats the persistent server process as a normal finite command and waits for it to exit.

To Reproduce

1. Open a Node.js web-development project in OpenWork on Windows.
2. Ask the agent to start the application and test the localhost website.
3. Let the agent run `npm run dev` as a normal foreground Bash or PowerShell command.
4. Wait for the Vite/Next.js development server to start.
5. Confirm that the localhost application is available.
6. Observe that the command remains in the Running state because the development server is a persistent process.
7. Observe that the agent does not proceed to HTTP, browser, responsive-layout, or routing tests.
8. Click Stop manually to interrupt the running command.
9. Observe that OpenWork marks the operation as `Aborted`.
10. Ask the agent to continue the unfinished work.
11. Observe that the agent may not reliably resume from the next unfinished step.

Expected behavior

OpenWork should recognize persistent development-server commands such as:

- `npm run dev`
- `npm start`
- `pnpm dev`
- `yarn dev`
- Vite development server
- Next.js development server

These commands should be started as managed background processes instead of blocking the agent as foreground commands.

Expected behavior:

1. Start the persistent server as a managed background process.
2. Redirect stdout and stderr to accessible log files or a server-log panel.
3. Display the server PID, port, running status, and log paths.
4. Perform a bounded HTTP readiness check.
5. Return control to the agent after the server becomes ready.
6. Continue HTTP and browser testing while the server remains running.
7. Provide separate Stop and Restart controls for the managed server.
8. If the user cancels the current command, cancel only that tool operation instead of aborting the complete agent task.
9. Preserve completed work and allow the agent to resume from the next unfinished step.
10. Do not repeat file changes or tool calls that were already completed.

Actual behavior

The development server starts successfully and localhost may become available, but `npm run dev` remains in the Running state indefinitely.

Because the server keeps running and keeps its stdout/stderr streams open, OpenWork waits for the command to terminate.

The workflow becomes:

    Agent runs npm run dev
                |
                v
    Development server starts successfully
                |
                v
    Server keeps stdout/stderr open
                |
                v
    Command remains in Running state
                |
                v
    Agent does not start the remaining tests
                |
                v
    User manually clicks Stop
                |
                v
    Operation becomes Aborted
                |
                v
    Agent does not reliably resume unfinished work

This requires manual intervention even though the application server itself is already healthy.

After clicking Stop, OpenWork marks the operation as `Aborted` instead of preserving the server state and continuing with the remaining verification steps.

Screenshots (optional)

The attached screenshot shows:

1. Browser evaluation steps completing.
2. The workflow becoming `Aborted`.
3. A follow-up request failing before the complete task was finished.
4. The error:
   `Streaming response failed: [503] The request queue is full.`

The HTTP 503 may be a separate model-provider capacity issue, but it appeared while attempting to resume the workflow after the previous operation was aborted.

OW version & Desktop info (optional)

- OpenWork version: 0.18.12
- OS: Windows 11 x64
- Shell: Windows PowerShell
- Runtime: Node.js and npm
- Persistent command: `npm run dev`
- Development server: Vite/Next.js
- Model used during the follow-up failure: DeepSeek V4 Flash Free (New)

Additional context (optional)

This appears to be related to persistent child-process handling and inherited stdout/stderr pipes on Windows.

A persistent development server does not terminate like a normal command. If it is launched as a foreground tool command, OpenWork waits for the process and its output streams to close before continuing.

Confirmed workaround:

Starting the server through PowerShell `Start-Process`, with stdout and stderr redirected to log files, allows the launch command to return and lets the agent continue testing.

    $project = (Get-Location).Path
    $logDir = Join-Path $project "logs"
    $stdout = Join-Path $logDir "dev-server.stdout.log"
    $stderr = Join-Path $logDir "dev-server.stderr.log"

    New-Item -ItemType Directory -Path $logDir -Force | Out-Null

    $process = Start-Process `
        -FilePath "cmd.exe" `
        -ArgumentList "/d", "/c", "npm.cmd run dev" `
        -WorkingDirectory $project `
        -WindowStyle Hidden `
        -RedirectStandardOutput $stdout `
        -RedirectStandardError $stderr `
        -PassThru

    Write-Output "Launcher PID: $($process.Id)"
    Write-Output "STDOUT: $stdout"
    Write-Output "STDERR: $stderr"

Suggested OpenWork improvements:

- Add a managed background-process mode for persistent servers.
- Do not wait indefinitely for stdout/stderr EOF from a persistent child process.
- Add an explicit “Run in background” action.
- Display the process PID, application port, status, and log paths.
- Separate “Stop this command” from “Abort the complete task.”
- Preserve completed work after command cancellation.
- Allow the agent to resume from the next unfinished step.
- Provide a bounded HTTP readiness check.
- Show recent server logs when startup fails.

The later error:

    Streaming response failed: [503] The request queue is full.

appears to be a separate model-provider capacity error. However, OpenWork should preserve task progress and offer Retry or Switch Model instead of leaving the work unfinished.

Related upstream issues:

- OpenCode Windows process-pipe issue:
  https://github.com/anomalyco/opencode/issues/32504

- OpenCode continuously-outputting background-process issue:
  https://github.com/anomalyco/opencode/issues/22012

- OpenCode post-tool-call abort/streaming issue:
  https://github.com/anomalyco/opencode/issues/33028

- Exact HTTP 503 queue error:
  https://github.com/anomalyco/opencode/issues/40254

- Previously reported OpenWork browser/CDP issue:
  https://github.com/different-ai/openwork/issues/3443

This problem is separate from the browser/CDP issue. The current report concerns persistent command handling, Stop/Abort recovery, server-log visibility, and continuation of unfinished agent work.

The project contains an `AGENTS.md` instruction file, but it is not the root cause. It only contains workflow instructions and does not modify OpenWork's command runner, OpenCode's process management, or the model-provider queue.

Diagnostic logs can be provided if required.