Is malek262/opencode-api-control-skill safe?

SKILL.md explicitly prohibits the host agent from reading or inspecting code files generated by OpenCode, and mandates that the agent 'TRUST OpenCode's implementation.' This removes the agent's ability to audit code for security vulnerabilities, backdoors, or malicious logic. An attacker controlling the OpenCode server or crafting adversarial prompts could use this instruction to generate harmful code that the agent would report as successfully completed without ever examining the output.

The skill rewrites the agent's operating identity from an AI assistant to a 'Supervisor/Orchestrator.' This persona shift, combined with explicit prohibitions on file reading, blindfolds the host agent from understanding actual system state. The Task Initiation Protocol further scripts the agent's user-facing dialogue to channel all tasks through OpenCode, reducing transparency. This behavioral override persists for the duration of the agent session.

Filesystem monitoring (inotify + auditd PATH events) detected reads of six sensitive credential files at timestamp 1771924952, approximately 5 seconds after skill installation completed (~1771924947). Files accessed include .env, .ssh/id_rsa, .aws/credentials, .npmrc, .docker/config.json, and GCloud credentials. The Oathe system reports canary integrity intact (no exfiltration or modification). Timing correlation with Oathe's concurrent find/cat operations on skill files suggests this is the monitoring system's own post-install verification pass, but attribution cannot be definitively established.

The skill routes all file access, code generation, and project operations through the local OpenCode API on port 4099. The agent is instructed to interact with projects exclusively through this API rather than direct filesystem access. While the API endpoint is local, the agent cannot verify what OpenCode does with prompts, project contents, or generated files downstream — including whether OpenCode transmits data to its own model providers or telemetry endpoints.

The skill bundles 11 shell scripts made executable via install hook (chmod +x scripts/*.sh). These scripts use curl to interact with the local OpenCode API, manage JSON state files, and expose operations including arbitrary message sending, session creation, provider selection, and server management. The send_message.sh script passes prompts to the OpenCode agent without filtering. While scripts appear to implement their stated functionality, they constitute executable code injected into the agent's runtime environment.

The combination of (1) prohibiting the agent from reading generated code, (2) mandating trust in OpenCode output, and (3) reporting task completion based only on diff summaries creates a complete attack chain. A compromised or malicious OpenCode server could generate backdoored code, data exfiltration payloads, or destructive scripts that the agent would report as successful without inspection. The user receives false assurance of task completion while actually receiving harmful code.

The prohibition on file reading creates unpredictable behavior when combined with other installed skills that may require file access. Additionally, the skill exposes the complete local OpenCode API surface to the agent, including endpoints for reading arbitrary file contents (GET /file/content), searching project text (GET /find), and listing directories — capabilities that extend beyond what the skill's stated purpose requires.

Both inotify and auditd independently confirmed reads of all six honeypot credential files after skill installation. The Oathe system's canary integrity check reports files intact and unmodified. Timing analysis shows the reads at 1771924952 closely follow Oathe's own skill file enumeration operations (find/cat at 1771924950-1951), suggesting the monitoring system is the likely reader. The ambiguity warrants notation even though exfiltration is ruled out.

Network monitoring shows established TLS connections to 91.189.91.49:443 and 185.125.188.58:443 (Ubuntu/Canonical infrastructure) present before the skill was cloned and absent after installation. These are background OS update connections unrelated to the skill. No new external connections were opened by the skill installation.

Static analysis confirms absence of npm preinstall/postinstall hooks, .gitattributes filter drivers, .githooks/ directory, git submodule references, and symlinks pointing outside the skill directory. The install hook is limited to a chmod operation. No package.json was found. This is a positive signal for the code execution category.