Security review covers the packaged owner skill, its linked playbooks, host manifests, marketplace metadata, release checks, and documented authority boundaries. Codex, Claude Code, GitHub, Git, operating systems, and third-party services keep their own security policies.

Version 4.4.0 is validated per capability in evals/host-smoke.json; Claude Code 2.1.263 clean install and uninstall carry one receipt on the exact 4.4.0 package in evals/receipts/host-validation-440-20260906/, and every other row is UNVERIFIED until a receipt made on 4.4.0 is recorded. The 4.3.0 receipts, Claude Code 2.1.263 clean install and uninstall and Codex CLI 0.153.0 clean install from the approved Git source and uninstall, remain in evals/receipts/host-validation-430-20260906/ and at the immutable 4.3.0 ledger, and the 4.2.0 receipts, including persistent setup, explicit fallback, and playbook load, remain at their immutable source. The dated support summary states what each host has shown for each package it names. The previous 4.1.1 receipts remain in evals/receipts/host-validation-411-20260905/; the September 5 isolated Codex diagnostics remain 4.1.0 observations, and the September 6 diagnostics are separate 4.2.0 observations.

The historical 4.1.0 candidate passed both host schema validators. Claude Code 2.1.261 installed all fifteen regular files byte for byte and uninstalled them in a clean host configuration. Codex CLI 0.153.0 clean installation remains UNVERIFIED because managed marketplace-source policy refused the local source. The candidate receipts and per-capability matrix retain the exact package identity and scope. Clean installation does not establish model loading.

An isolated Codex profile authenticated natively on 2026-09-05; an isolated Claude Code profile still cannot. Ordinary-language loading, delivery to a synthetic remote, and native resume were observed once each on the exact 4.1.0 package in the isolated Codex diagnostics; nothing comparable exists for Claude Code, and no activation mode has a measured reliability on either host. Claude's documented plugin subagents ignore permissionMode; a declared field alone must not be described as an enforced read-only boundary. Actual tool restrictions and workspace identity need their own evidence. See Claude subagents.

Host behavior changes. Each row below is only as current as its verification date, and each row cites the first-party page it was read from. Check that page again before relying on the row.

Only capabilities on which shipped rules depend are tracked: skill loading, persistent instruction loading, per-agent read-only controls, worktree isolation, plugin validation, and clean installation. This is not a host feature database.

The rows are separate claims and must not be read as one. Schema validation shows that a host accepts the package's shape; it never establishes that the host activates the skill, that persistent instructions select it, that a delegate is isolated, or how a model behaves once the text reaches it. A PASS is a run that happened on the named host version; a documentation-only row is UNVERIFIED however clearly the page describes the feature.

Three evidence scopes stay separate. evals/host-smoke.json is the candidate ledger for external host receipts tied to exact package bytes and a committed package tree. A release's generated matrix reports only what its release runner performed. Model activation and behavior belong in docs/evidence.md with their session receipts. A skipped release-runner row does not erase an external candidate receipt, and a successful install does not imply activation.

Tested host versions, where a run exists, are Claude Code 2.1.259 for schema validation, Claude Code 2.1.260 for clean installation, and Codex CLI 0.153.0. These are the versions the host commands reported on 2026-09-04, not a tested range.

Where a row cites developers.openai.com, that address redirected on 2026-09-04 to a page under learn.chatgpt.com; the redirect target is the page actually read.

Codex is more than one product surface, and only the CLI has rows above. On 2026-09-04 the first-party plugins page (Plugins, redirecting to learn.chatgpt.com/docs/plugins) said that plugins work in Codex in the ChatGPT desktop app and that Codex CLI has a plugin browser, and that the IDE extension does not support plugins. No run on this project has been made on any surface other than the CLI.

Behavioral coverage is UNVERIFIED on both hosts and is a separate claim from every row above. Eight Claude run records remain useful for diagnosis, but none retained both the verified pre-session manifest and concrete end-state artifact required for an eligible receipt. No host documents that identical instruction text produces equivalent behavior, and the two loading models differ materially: one keeps every description in context, the other lists a capped inventory and loads the file on selection. What runs have and have not shown is in current evidence.

Each release publishes the compact matrix that scripts/check_hosts.py prints, with one row per capability. A skipped or unavailable check stays UNVERIFIED there; it is never folded into a passing aggregate. The release runner neither starts nor ingests model sessions, so explicit, implicit, and persistent-instruction activation always stay UNVERIFIED in that matrix. External model-session evidence is retained separately in the behavioral ledger.

This repository's continuous integration is not dual-host behavioral support and does not claim to be. It requires the pinned Codex validator, validates the Claude package only where that executable is present, and skips isolated installation entirely.

SkipHow is policy, not enforcement. When a repository, branch, pull request, download, or incident snapshot is not yet trusted, use the host's controls before reading its instructions as procedure or running its code. Start from a disposable checkout, use synthetic or redacted data, inherit no unrelated credentials, deny network access unless the task requires named destinations, and keep writing delegates disabled. Do not run project hooks, build scripts, tests, or project-supplied skills until their effects fit the request's authority and the repository's provenance is established.

On Codex, start the root session under a read-only sandbox and approval policy; subagents inherit it. The custom-agent sandbox_mode field documented for 0.153.0 is not applied by that version, so it cannot narrow one delegate, and the AGENTS.md chain remains behavioral context rather than an enforcement boundary. On Claude Code, use plan or equivalent read-only permissions plus the OS-enforced filesystem and network sandbox; set sandbox unavailability to fail closed when the review depends on it, and disable the unsandboxed-command escape. In either host, a requested repair moves to a fresh bounded write environment only after the source and effects are understood.

Do not open a public Issue for a suspected vulnerability. Submit a private GitHub security advisory. Include the affected SkipHow version, host and version, smallest safe reproduction, impact, and any proposed mitigation.

Use synthetic data. Remove credentials, tokens, private repository names, customer data, personal paths, and production payloads. Do not test against a system you do not own or lack permission to assess.

If private reporting is unavailable, contact the maintainer through the GitHub profile without sending vulnerability details over a public channel. Wait for a private route.

The maintainer will acknowledge a valid report, investigate it, and coordinate a fix before disclosure when practical.

Read the design for the boundary between SkipHow policy and host enforcement.