OpenCode Desktop crashes on Windows when workspace contains very long generated paths

Description

OpenCode Desktop crashes on Windows when workspace contains very long generated paths

Summary

OpenCode Desktop on Windows may intermittently lose its local backend/server when a workspace contains deeply nested, automatically generated files with very long absolute paths.

The visible symptom is that the OpenCode UI may remain open, but the local backend listening on 127.0.0.1:<dynamic-port> disappears.

During troubleshooting, the failing process was identified as an OpenCode utility process running as a Node service:

OpenCode.exe
  --type=utility
  --utility-sub-type=node.mojom.NodeService

A crash dump captured during reproduction showed:

Exception: E06D7363.?AVregex_error@std@@
Unhandled: C0000409

The affected workspace contained generated paths up to approximately 324 characters.

Moving the generated persistent data outside the OpenCode workspace stopped the crashes in subsequent validation tests.

---

Environment

• OS: Windows
• Application: OpenCode Desktop
• Container runtime: Docker Desktop
• Shell: Windows PowerShell
• Workspace: local Windows directory
• Workload involved:
  • Docker Compose
  • Python application
  • HashiCorp Vault using the file storage backend
• OpenCode backend:
  • local listener on 127.0.0.1
  • dynamic TCP port
  • OpenCode.exe --type=utility --utility-sub-type=node.mojom.NodeService

No credentials, tokens, private keys, or production data are required to reproduce the issue.

---

Initial symptom

The problem initially appeared while OpenCode executed commands such as:

docker exec app-backend python /app/verify_service.py

and:

docker compose run ...

The OpenCode local backend would disappear during or shortly after some executions.

At first, the issue appeared related to Docker, TTY handling, PowerShell quoting, stdout/stderr streaming, Python, or the application itself.

Those possibilities were tested individually.

---

Isolation performed

The following operations worked correctly without crashing OpenCode:

echo TEST
docker ps
docker exec <container> echo TEST
docker exec <container> python --version
docker exec <container> python -c "print('OK')"
Python framework import
framework setup/initialization
client library initialization
authenticated API read
secret write
secret read
encryption operation
decryption operation
application key loading

The application tests also completed successfully.

This showed that the crash was not caused directly by:

• Docker CLI
• docker exec
• Python startup
• framework initialization
• network connectivity
• the secret-management API
• stdout/stderr volume
• the application roundtrip itself

The behavior was intermittent, which initially made the triggering condition difficult to identify.

---

Process-level evidence

The OpenCode process listening on the local dynamic port was identified using PowerShell:

$opids = (Get-Process OpenCode).Id

Get-NetTCPConnection -State Listen |
    Where-Object { $opids -contains $_.OwningProcess } |
    Select-Object LocalAddress, LocalPort, OwningProcess

The listener belonged to:

OpenCode.exe
--type=utility
--utility-sub-type=node.mojom.NodeService

When the issue occurred:

Main OpenCode process: UP
NodeService process:   DOWN
Local listener:        DOWN

The main desktop process remained running.

---

Exit status

A Win32_ProcessStopTrace event was used to capture the process termination.

Observed result:

ProcessName : OpenCode.exe
ExitStatus  : 3221226505

Hexadecimal:

0xC0000409

This is a Windows fail-fast style termination status.

---

Crash dump evidence

Sysinternals ProcDump was attached to the OpenCode NodeService process.

Example command:

procdump.exe -accepteula -ma -e -t <PID> C:\Temp\OpenCodeDumps

When the issue reproduced, ProcDump reported:

Exception: E06D7363.?AVregex_error@std@@
Unhandled: C0000409

A full dump was successfully generated.

The std::regex_error immediately before the fail-fast termination became the most relevant diagnostic clue.

---

Workspace finding

The affected project contained persistent application data inside the workspace.

Example layout:

C:\Work\ExampleProject\
├── backend\
├── frontend\
├── config\
└── data\
    └── service-data\

A Docker service used a bind mount similar to:

volumes:
  - ./data/service-data:/service/data

The service generated deeply nested paths containing identifiers and metadata files.

Example pattern:

C:\Work\ExampleProject\data\service-data\
  logical\
    <generated-id>\
      <generated-id>\
        metadata\
          <generated-name>

The longest paths found in the workspace were approximately:

324 characters

PowerShell was used to locate the longest paths:

Get-ChildItem "C:\Work\ExampleProject" -Recurse -Force -ErrorAction SilentlyContinue |
ForEach-Object {
    [PSCustomObject]@{
        Length = $_.FullName.Length
        Path   = $_.FullName
    }
} |
Sort-Object Length -Descending |
Select-Object -First 20

The longest entries were all inside the generated persistent-data tree.

---

Important observation

Creating a normal file in the workspace did not reproduce the issue.

Creating a normal file inside the persistent-data directory also did not immediately reproduce it.

Therefore, this does not appear to be a generic "any filesystem change crashes OpenCode" problem.

The stronger correlation was with:

• deeply nested generated paths;
• long absolute path lengths;
• application-generated filesystem activity;
• a native std::regex_error;
• termination of the OpenCode NodeService.

---

Workaround / solution

The persistent generated data was moved outside the OpenCode workspace.

Before:

volumes:
  - ./data/service-data:/service/data

After:

volumes:
  - C:/ContainerData/ExampleProject/service-data:/service/data

The data was copied to the new location while the service was stopped.

Example workflow:

docker compose stop service

New-Item -ItemType Directory `
    -Path "C:\ContainerData\ExampleProject\service-data" `
    -Force

robocopy `
    "C:\Work\ExampleProject\data\service-data" `
    "C:\ContainerData\ExampleProject\service-data" `
    /E /COPY:DAT /DCOPY:DAT /R:2 /W:1

Then the Docker Compose bind mount was changed to the external location and the service was restarted.

After validating the migrated data, the old generated directory was removed from the OpenCode workspace.

---

Validation after workaround

After moving the generated persistent data outside the workspace:

• the service started normally;
• previously stored data remained accessible;
• read/write operations succeeded;
• encryption/decryption verification succeeded;
• application-specific key loading succeeded;
• application tests passed;
• the previously problematic verification command completed successfully;
• the OpenCode NodeService remained running during the validation.

Example application test result:

Found 5 test(s).
Ran 5 tests.
OK

---

Expected behavior

OpenCode should safely observe or ignore deeply nested and long filesystem paths without terminating its local NodeService.

A filesystem watcher error should not cause the entire local backend process to fail-fast.

---

Actual behavior

Under certain filesystem activity involving very long generated paths inside the workspace:

std::regex_error

is observed in the OpenCode NodeService process, followed by:

0xC0000409

The NodeService exits and the OpenCode local backend listener disappears.

---

Suspected root cause

The evidence suggests a bug in the native filesystem-watching/path-matching layer used by OpenCode Desktop on Windows.

The most relevant indicators are:

1. std::regex_error immediately before termination.
2. Fail-fast exit status 0xC0000409.
3. Only the OpenCode NodeService terminates.
4. The issue is workspace-dependent.
5. The workspace contained generated paths exceeding 300 characters.
6. Moving the generated data outside the workspace stopped the observed crashes during subsequent validation.

This report does not claim that every long path will reproduce the crash.

The trigger appears intermittent and may depend on a particular filesystem-event pattern, path-matching expression, timing condition, or combination of those factors.

---

Suggested reproduction scenario

A minimal reproduction may be possible with:

1. Open a local Windows directory in OpenCode Desktop.
2. Generate a deeply nested directory tree inside the workspace.
3. Include absolute paths exceeding 300 characters.
4. Continuously create/update files under those paths.
5. Execute normal shell commands through OpenCode while filesystem activity occurs.
6. Monitor the OpenCode NodeService process and local TCP listener.

Useful monitoring command:

$opids = (Get-Process OpenCode).Id

Get-NetTCPConnection -State Listen |
    Where-Object { $opids -contains $_.OwningProcess } |
    Select-Object LocalAddress, LocalPort, OwningProcess

For crash capture:

procdump.exe -accepteula -ma -e -t <NODE_SERVICE_PID> C:\Temp\OpenCodeDumps

---

Recommended mitigation for users

Until the underlying watcher issue is fixed:

• keep database storage outside the workspace;
• keep Vault/file-based secret storage outside the workspace;
• keep Docker persistent data outside the workspace;
• avoid generated trees with UUID/hash-based deep nesting inside directories watched by OpenCode;
• store persistent container data in paths such as:

C:\ContainerData\<project>\

and keep the OpenCode workspace focused on:

• source code;
• configuration;
• documentation;
• tests;
• small development artifacts.

---

Additional diagnostic artifacts available

The following evidence can be provided privately if required:

• ProcDump full crash dump;
• exact Win32_ProcessStopTrace exit status;
• OpenCode log immediately before the crash;
• sanitized Docker Compose example;
• sanitized list of long workspace paths;
• process hierarchy showing the failing NodeService.

The full memory dump should not be uploaded publicly without sanitization/review.

Plugins

No response

OpenCode version

OpenCode Desktop 1.18.30

Steps to reproduce

Steps to reproduce

1. On Windows, open a local project directory with OpenCode Desktop.

2. Inside the workspace, configure a Docker service that stores persistent generated data using a bind mount, for example:

   volumes:
     - ./data/service-data:/service/data
   

3. Run a service that creates deeply nested directories and files inside that mounted path, especially paths containing generated IDs, hashes, UUIDs, metadata directories, or similarly long names.

4. Verify that some absolute paths inside the OpenCode workspace exceed approximately 260–300 characters.

   Example PowerShell command:

   Get-ChildItem "C:\Work\ExampleProject" -Recurse -Force -ErrorAction SilentlyContinue |
   ForEach-Object {
       [PSCustomObject]@{
           Length = $_.FullName.Length
           Path   = $_.FullName
       }
   } |
   Sort-Object Length -Descending |
   Select-Object -First 20
   

5. Keep OpenCode Desktop open on that workspace and start the Docker services.

6. From OpenCode, execute commands that cause the containerized service to read/write data in the bind-mounted directory, for example:

   docker exec app-backend python /app/verify_service.py
   

7. Repeat the operation if necessary. The issue may be intermittent and does not reproduce on every execution.

8. Observe that the OpenCode UI may remain open, but its local backend becomes unavailable.

9. Check which OpenCode process owns the local listener:

   $opids = (Get-Process OpenCode).Id
   
   Get-NetTCPConnection -State Listen |
       Where-Object { $opids -contains $_.OwningProcess } |
       Select-Object LocalAddress,LocalPort,OwningProcess
   

10. When the issue occurs, the OpenCode.exe process running as:

    --type=utility
    --utility-sub-type=node.mojom.NodeService
    

    terminates and the local 127.0.0.1:<dynamic-port> listener disappears.

11. If ProcDump is attached to that process:

    procdump.exe -accepteula -ma -e -t <PID> C:\Temp\OpenCodeDumps
    

    the crash may show:

    Exception: E06D7363.?AVregex_error@std@@
    Unhandled: C0000409
    

12. Move the generated persistent data outside the OpenCode workspace, for example:

    volumes:
      - C:/ContainerData/ExampleProject/service-data:/service/data
    

13. Restart the services and repeat the same OpenCode commands.

14. Observe that the previously failing operations complete successfully and the OpenCode NodeService remains running.

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response