OpenCode tasks bypass Claude Code project permission deny rules

[JohnnyVicious]

Summary

OpenCode runs outside Claude Code's own tool permission system. A project-level .claude/settings.json deny rule that blocks Claude from reading or editing a file may not stop /opencode:rescue from asking OpenCode to inspect or modify that same file.

This is a security-model gap rather than a transport bug.

Local evidence

/opencode:rescue forwards user text to opencode-companion.mjs task, which sends a prompt to the OpenCode HTTP server. OpenCode then uses its own agent/tool permissions, not Claude Code's Read(...), Edit(...), or deny-list enforcement.

Read/write task defaults are also broad:

• handleTask() defaults isWrite to true.
• buildTaskPrompt() tells OpenCode: You have full read/write access. Make the necessary code changes.

Expected behavior

The plugin should either respect project-level Claude Code deny rules or document clearly that OpenCode has an independent permission boundary.

Suggested fix

At minimum:

1. Document the permission boundary in README and /opencode:setup output.
2. Warn when .claude/settings.json contains deny rules and the user starts a write-capable rescue task.

Potential stronger fix:

1. Parse applicable deny rules from .claude/settings.json.
2. Inject explicit forbidden paths into the task prompt.
3. For OpenCode tool configuration, disable or constrain tools when the requested task overlaps denied paths, if OpenCode exposes a suitable control surface.

Upstream reference

Derived from openai/codex-plugin-cc#75.

[JohnnyVicious]

Fixed in PR #56: the companion now reads .claude/settings.json deny rules on every write-capable task and emits a stderr warning listing the blocked paths, so users can make an informed choice. README updated to document the permission boundary.