[Bug]: [Windows] Detached Next.js server becomes healthy but command remains Running indefinitely

[mauryaankur99]

Summary

On Windows, OpenWork/OpenCode does not complete a PowerShell command after it launches a persistent Next.js server with Start-Process, even when the process is detached and stdout/stderr are redirected to log files.

The Next.js server starts successfully, becomes ready in 192ms, listens on port 3000, and returns HTTP 200. However, OpenWork continues displaying the server-launch command as `Running` indefinitely and does not proceed to the next verification step.

Clicking Stop cancels the OpenWork tool operation, but the detached Next.js process remains alive and continues returning HTTP 200.

This confirms that the application and server startup are successful. The failure is in OpenWork/OpenCode's Windows process-lifecycle tracking: the tool call does not settle after the launcher command has completed because a persistent child process remains alive.

To Reproduce

1. Open a Next.js project in OpenWork on Windows.

   2. Run a successful production build:

      npm run build

   3. Confirm that the build completes with exit code 0.

   4. Ask OpenWork to start the production server as a detached Windows process with stdout and stderr redirected to files.

   5. The equivalent PowerShell operation is:

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

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

      $process = Start-Process -FilePath "node"
      -ArgumentList "node_modules/next/dist/bin/next", "start", "-p", "3000" -WorkingDirectory $project
      -RedirectStandardOutput $outLog -RedirectStandardError $errLog
      -WindowStyle Hidden `
      -PassThru

      Write-Output "Launcher PID: $($process.Id)"
      Write-Output "STDOUT: $outLog"
      Write-Output "STDERR: $errLog"

   6. Observe that the Next.js server starts successfully.

   7. Check logs/server.stdout.log. It reports:

      Next.js 16.2.11
      Local: http://localhost:3000
      Ready in 192ms

   8. Check logs/server.stderr.log. The file is empty and has a size of 0 bytes.

   9. Check port 3000 from an external PowerShell terminal:

      $connection = Get-NetTCPConnection -LocalPort 3000
      -State Listen `
      -ErrorAction SilentlyContinue |
      Select-Object -First 1

      $connection.OwningProcess

   10. Confirm that a Node.js process is listening:

       Process name: node.exe
       PID: 24480
       Command line: node_modules/next/dist/bin/next start -p 3000

   11. Perform an HTTP request from an external PowerShell terminal:

       Invoke-WebRequest -Uri "http://127.0.0.1:3000"
       -UseBasicParsing `
       -TimeoutSec 10

   12. Confirm that the server returns:

       HTTP status: 200
       Response size: 27598 bytes

   13. Return to OpenWork.

   14. Observe that OpenWork still displays the launch operation as:

       Running 1 command

   15. Wait several minutes.

   16. Observe that the command never transitions to completed or failed, and the agent does not proceed to the next task step.

   17. Click Stop in OpenWork.

   18. Check port 3000 and the HTTP endpoint again from the external PowerShell terminal.

   19. Confirm that the detached server remains alive and still returns HTTP 200 after the OpenWork operation is cancelled.

Expected behavior

After Start-Process successfully launches the detached server and returns, OpenWork should mark the PowerShell tool call as completed.

The persistent child server should remain running independently, while the agent continues to the next finite verification step.

Expected workflow:

    OpenWork executes PowerShell launcher
                    |
                    v
    Start-Process creates detached server
                    |
                    v
    Launcher prints PID and log paths
                    |
                    v
    PowerShell launcher returns
                    |
                    v
    Tool call transitions to Completed
                    |
                    v
    Agent performs bounded readiness check
                    |
                    v
    Agent continues HTTP/browser verification

OpenWork should not wait for the detached Next.js child process to terminate.

OpenWork should also:

1. Treat the PowerShell launcher and the persistent server as separate process lifecycles.
2. Complete the tool call when the launcher process returns.
3. Avoid waiting for EOF from stdout/stderr handles belonging to a persistent child or grandchild process.
4. Preserve the PID and log paths for the managed server.
5. Continue the agent workflow after a bounded readiness check.
6. Provide explicit background-process controls for status, logs, stop, and restart.
7. Separate “Stop the current tool call” from “Abort the complete agent task.”
8. Preserve completed work when a tool operation is cancelled.
9. Never launch a second server automatically while the first server is already healthy.
10. Return a clear timeout or process-lifecycle error instead of remaining `Running` indefinitely.

Actual behavior

The detached Next.js server starts successfully and becomes fully healthy:

- Production build: successful
- Build exit code: 0
- Next.js version: 16.2.11
- Server startup time: 192ms
- Listening port: 3000
- Server process: node.exe
- Server PID during reproduction: 24480
- Server command: node_modules/next/dist/bin/next start -p 3000
- HTTP status: 200
- HTTP response size: 27598 bytes
- server.stderr.log size: 0 bytes

Despite this, OpenWork remains on:

    Running 1 command

The agent does not proceed to the next verification step.

The workflow currently behaves like this:

    OpenWork launches Start-Process
                    |
                    v
    Next.js server starts successfully
                    |
                    v
    Server becomes ready in 192ms
                    |
                    v
    Port 3000 starts listening
                    |
                    v
    HTTP request returns 200
                    |
                    v
    OpenWork command remains Running
                    |
                    v
    Agent does not continue
                    |
                    v
    User manually clicks Stop
                    |
                    v
    OpenWork tool operation becomes Aborted
                    |
                    v
    Detached server remains alive and healthy

The successful server startup, empty stderr log, listening TCP port, and HTTP 200 response demonstrate that this is not an application startup failure.

The OpenWork/OpenCode command lifecycle remains pending even though the PowerShell launcher has completed its useful work.

Screenshots (optional)

No screenshots are attached.

The issue has been verified with textual diagnostics:

- Build completed successfully with exit code 0.
- `logs/build.log` was created successfully.
- `logs/server.stdout.log` reported Next.js 16.2.11 and `Ready in 192ms`.
- `logs/server.stderr.log` was empty.
- Windows reported `node.exe` listening on port 3000.
- The process command line was `node_modules/next/dist/bin/next start -p 3000`.
- An external HTTP request returned status 200 with a response size of 27598 bytes.
- OpenWork still displayed the launch command as Running.
- After clicking Stop in OpenWork, the detached server remained alive and continued returning HTTP 200.

Additional logs can be provided if required.

OW version & Desktop info (optional)

• OpenWork version: 0.18.18
  • OS: Windows 11 x64
  • Shell: Windows PowerShell 5.1
  • Node.js executable: C:\Program Files\nodejs\node.exe
  • Framework: Next.js 16.2.11
  • Application mode: Next.js production server
  • Server command: node_modules/next/dist/bin/next start -p 3000
  • Application port: 3000

Additional context (optional)

This issue is reproducible on the current installed OpenWork version, v0.18.18.

I reviewed the v0.18.18 release notes and the changes since v0.18.13, but could not find a documented fix for Windows persistent-process handling, inherited stdout/stderr pipes, or detached PowerShell Start-Process commands remaining in the Running state.

The Next.js server itself starts successfully, becomes ready, listens on port 3000, and returns HTTP 200. However, OpenWork continues showing the launcher command as Running indefinitely and does not proceed to the next agent step.

The problem was first observed when OpenWork ran a persistent development or production server as part of a multi-step coding and verification task.

Initially, a foreground `npm run dev` or `npm run start` command was expected to remain active because a development server is persistent.

To avoid blocking the agent, the server was changed to a detached `Start-Process` launch with:

- A separate process
- An explicit working directory
- stdout redirected to `logs/server.stdout.log`
- stderr redirected to `logs/server.stderr.log`
- `-PassThru` enabled
- A bounded readiness check

However, OpenWork still remained in the Running state after the server started successfully.

The final diagnostic sequence conclusively showed:

    Build completed with exit code 0
                    |
                    v
    Detached server started
                    |
                    v
    Next.js reported Ready in 192ms
                    |
                    v
    stderr remained empty
                    |
                    v
    node.exe listened on port 3000
                    |
                    v
    External HTTP request returned 200
                    |
                    v
    OpenWork tool call remained Running
                    |
                    v
    User clicked Stop
                    |
                    v
    Server survived cancellation
                    |
                    v
    External HTTP request still returned 200

This appears to be a Windows process-tree or inherited-handle lifecycle problem.

A possible cause is that OpenWork/OpenCode waits for a process-tree output stream, pipe, process handle, or tool fiber to settle even though the PowerShell launcher has returned and the persistent child process has its output redirected to files.

Suggested implementation directions:

1. Resolve the tool call based on the foreground launcher process exit rather than waiting indefinitely for child-process stream EOF.
2. Stop reading or detach inherited pipes after a short grace period following launcher exit.
3. Ensure redirected persistent child processes do not keep the tool execution promise pending.
4. Add an overall deadline while waiting for tool fibers to settle.
5. Return a clear error if the command lifecycle cannot settle.
6. Add a first-class managed background-process mode.
7. Store the background process PID, port, command, working directory, and log paths.
8. Add a finite readiness check that is separate from process completion.
9. Do not launch duplicate server instances if the configured port is already healthy.
10. Add Windows-specific automated tests for persistent Node.js, Vite, Next.js, and Python server processes.
11. Test cancellation behavior and verify that cancelling a tool does not corrupt the broader agent session.
12. Expose server-process status and logs in the OpenWork interface.

Confirmed workaround:

Start the persistent server manually in a separate external PowerShell terminal and instruct OpenWork not to start, stop, restart, rebuild, or manage the server.

OpenWork can then perform only finite HTTP and browser verification commands.

Related upstream OpenCode issues:

- Windows spawned-process stdout/stderr pipe hang:
  https://github.com/anomalyco/opencode/issues/32504

- Continuously-outputting background process keeps Bash tool pending:
  https://github.com/anomalyco/opencode/issues/22012

- Agent or subagent hangs after Bash tool calls:
  https://github.com/anomalyco/opencode/issues/33028

This issue is separate from the previously reported OpenWork browser/CDP timeout problem. The current report concerns PowerShell/Node.js process lifecycle handling and persistent server commands.

The project contains an `AGENTS.md` instruction file that explicitly requires sequential execution, detached server startup, output redirection, bounded readiness checks, and no duplicate server launches.

The instruction file did not cause this problem. The detached server started correctly, but OpenWork did not complete the associated tool call.

No secrets, credentials, private environment variables, or confidential logs are included in this report.

[abhisheksharma611]

I confirm this has also happened to me. And it is so frustrating when agent remain stuck in the command and it never continue its work. We have to manually stop it and then after telling it then again start working and it happened to me many times. Please dev look into it as soon as possible. Thank you

[Edeys]

Same issue here — reproduced on my machine. Adding real evidence:

Environment:

• OpenWork: desktop app (Windows)
• OS: Windows 11 Pro 22H2 (build 22621, 64-bit)
• Trigger: agent runs a long PowerShell command via the bash tool, e.g. Start-Sleep -Seconds 120 (also reproduced with SSH/SCP commands that spawn a child process)

Observed behavior:

1. Agent invokes a long-running PowerShell command (Start-Sleep 120+, or an SSH/SCP transfer that stays alive).
2. The command shows "Running" indefinitely and never settles, even after the underlying process has finished.
3. After roughly the tool timeout, the call aborts with "User aborted the command" — despite no user interaction.
4. There is no recovery UI: the agent session is stuck and the next command has to be re-issued manually.

Impact: Any long-running or child-process-spawning command (waits, transfers, server starts) breaks the agent loop on Windows, making multi-step automation workflows unreliable.

This report was prepared with AI assistance; all reproduction steps and environment details are real.