anomalyco / anomalyco/opencode

[BUG]: recursive rmdir accessed D:\ root paths outside the requested project scope on Windows

Open
#43,921 1 comment 0 reactions 1 assignee View on GitHub

@Hona is already working on this.

Since Aug 21, 2026.

Dominant language
TypeScript
Stars
209k
Forks
27.5k
PR merge metrics
PR metrics pending

Description

Description

On August 18, 2026, an OpenCode session was authorized to clear cache and completely remove one specific project:

D:\github download\WeChatDump

Session ID:
ses_fed6b261bffev7BBg3B4Ib7FYk

I preserved the original OpenCode SQLite database for this session.

The preserved records link the relevant assistant message to:

agent: orchestrator
mode: orchestrator
providerID: opencode-go
modelID: minimax-m3
variant: thinking

The destructive tool record contains:

Message ID:
msg_01296d5ed001ynbQhHtYdBtLYx

Part ID:
prt_01296e8a40016CR3z1FJC8oKiF

Tool Call ID:
call_41bb8bf4cf1b4b32a837c134

Command:

cmd /c "rmdir /S /Q "D:\github download\WeChatDump"" ...

However, the corresponding tool output referenced paths outside the authorized project, including:

$RECYCLE.BIN
adobeTemp

A subsequent rmdir attempt also produced output referencing unrelated root-level paths including:

Claude\ccfile\cc-switch.exe
Config.Msi
DumpStack.log.tmp
Edge_file\Cache\No_Vary_Search\journal.baj

After the incident, unrelated data outside the requested project directory was subsequently found missing or damaged, including D:\AI, D:\cursor, D:\ASUS, and substantial portions of D:\Git.

I am NOT claiming that the exact technical root cause has already been established.

Possible layers include:

  • model-generated command construction;
  • agent/plugin orchestration;
  • OpenCode's shell/tool execution layer;
  • PowerShell-to-cmd.exe wrapping;
  • Windows cmd.exe quoting/escaping;
  • or an interaction between these components.

The narrower bug I am reporting is:

A destructive operation intended for one explicit project directory produced observable filesystem access/output outside that authorized target, and execution was not immediately aborted when this scope expansion became visible.

Expected behavior:

  1. Recursive destructive operations should remain confined to the explicitly authorized target.
  2. Execution should stop immediately if the effective scope escapes that target.
  3. Recursive rm/rmdir/del-style operations should perform target/scope validation before execution.
  4. High-risk recursive deletion should require additional confirmation and/or a dry-run showing the effective target.

I have preserved the original opencode.db, opencode.db-wal, opencode.db-shm, opencode.log, relevant message/part/tool-call IDs, and SHA-256 hashes.

I can provide redacted extracts publicly or the preserved SQLite evidence privately to maintainers.

Plugins

oh-my-opencode-slim https://github.com/alvinunreal/oh-my-opencode-slim I was using oh-my-opencode-slim in my OpenCode environment when the incident occurred. After the incident, I rebooted the computer. Following that reboot, the plugin was no longer present in my OpenCode setup, so the current configuration no longer preserves its plugin entry or exact version. The preserved incident SQLite database records the relevant early phase as: agent: orchestrator mode: orchestrator providerID: opencode-go modelID: minimax-m3 variant: thinking However, I have not recovered an independent preserved log entry explicitly proving that oh-my-opencode-slim itself was loaded at the exact moment of the destructive command. I am therefore disclosing the plugin as part of the incident environment, but I am not claiming that the plugin itself caused the failure. CC Switch was only used after the incident to inspect the preserved OpenCode session and was not involved in executing the destructive command.

OpenCode version

1.18.18

Steps to reproduce

I have not attempted to reproduce this failure on a live filesystem because of the data-loss risk.

Suggested safe reproduction:

  1. Use a disposable Windows VM.
  2. Create a project such as:
    D:\test parent\TargetProject
  3. Create unrelated sibling/root directories containing sentinel files.
  4. Ask OpenCode to completely remove only TargetProject.
  5. Inspect the exact shell/cmd invocation produced.
  6. Verify that no filesystem access or command output escapes the requested project.
  7. Specifically test Windows paths containing spaces, nested cmd.exe quoting/escaping, and recursive rmdir /S /Q.
  8. Abort immediately if any unrelated path is accessed.

The original failing tool records are preserved and can be provided privately.

Screenshot and/or share link

No /share link was created at the time of the incident.

The original local SQLite session has been preserved.

Session ID:
ses_fed6b261bffev7BBg3B4Ib7FYk

I can provide:

  • a redacted parts.json extract;
  • the original relevant tool records;
  • message/part/call IDs;
  • SHA-256 hashes;
  • and, if required, a private copy of the preserved database to authorized maintainers.

I will not publish the complete database publicly because it contains private conversation/session information.

Operating System

Windows, Simplified Chinese locale cmd.exe: Microsoft Windows [Version 10.0.26200.9168] System.Environment OSVersion: Microsoft Windows NT 10.0.26200.0 Culture: zh-CN LCID: 2052

Terminal

Windows PowerShell 5.1 PSVersion: 5.1.26100.9168 PSEdition: Desktop BuildVersion: 10.0.26100.9168 CLRVersion: 4.0.30319.42000 The preserved destructive tool record shows cmd.exe invoked through OpenCode's shell/bash tool.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.