opencode-sandbox

SUSPICIOUS. The skill’s purpose is coherent, but its default footprint is too broad for a sandbox helper: it mounts SSH keys, GitHub auth, and git identity into a personal third-party container image and enables autonomous push/PR/merge actions via `--auto`. The main concern is credential forwarding and supply-chain trust in the non-official mutable container image, not hidden malware.

The fragment documents a high-risk container configuration rather than malware. By default, sensitive SSH and GitHub credentials are exposed to an automatically approving agent, enabling unauthorized repository and organization actions if the task, agent, or mounted configuration is compromised. Credentials should be opt-in for untrusted or read-only work, and `--auto` should not be combined with broad credentials unless the task is explicitly trusted.

The fragment is documentation for a privileged Docker/OpenCode workflow, not malware itself. It presents a meaningful security risk when used with untrusted tasks because SSH and GitHub credentials are mounted by default and an automated agent can modify the workspace and perform GitHub write operations. Review the referenced scripts, Docker image, and mount configuration before use; prefer --no-ssh --no-github for untrusted work.

This fragment appears to be a legitimate Docker-based OpenCode launcher, not an overtly malicious payload. It creates a container with a writable project directory and, by default or selectable options, can expose SSH credentials, GitHub tokens, Git configuration, and developer profiles. A compromised image or OpenCode task could use these mounts and tokens to modify the project, access repositories, or authenticate to external services. Review the image provenance and consider disabling SSH/GitHub mounts, using read-only mounts, and avoiding token injection unless required.

This is documentation for an interactive Docker/OpenCode workflow, not apparent malware. However, it presents significant security exposure by granting an AI-driven container access to SSH keys, GitHub tokens, repository files, and configuration data. The unpinned remote installer and mutable Docker image also create supply-chain integrity risks. Use least-privilege mounts, avoid credential mounts when unnecessary, pin and verify scripts/images, and isolate the container.