install-codex-agents
Install, refresh, or check crux's Codex role agents in the personal or specified project directory. Preserve conflicting roles.
- License 许可
- MIT
- 最近更新
- 2026-11-12
- Stars
- ★ 0
- Forks
- 0
01 前言 Front Matter
- name
- install-codex-agents
- metadata
- { "tags": "codex, agents, installation, roles", "bundles": "crux-infrastructure, crux-docs", "triggers": "install codex agents | install crux agents for codex | refresh the codex agents", "risk_level": "medium", "requires_access": "write-host" }
- description
- Install, refresh, or check crux's Codex role agents in the personal or specified project directory. Preserve conflicting roles.
- disable-model-invocation
- true
02 资源文件 2
- 参考文档references/fresh-session-verification.md5.3 KB
- 脚本scripts/install.py5.0 KB
03 SKILL.md 正文
Install Codex Agents
<!-- BEGIN GENERATED: runtime-compat -->
Runtime compatibility
This skill is portable across Claude Code, Codex, OpenCode, and OMP (Oh My Pi). This section overrides platform-specific labels below.
- Before running a command that uses
CRUX_PLUGIN_ROOT, set it to the installed plugin root. In Claude Code, use the value ofCLAUDE_PLUGIN_ROOT. In Codex, OpenCode, and OMP, derive it from the absolute path of this selectedSKILL.md: the plugin root is the parent of itsskills/directory (in OMPbash,skill://<name>resolves to the skill directory). In a source checkout, use the checkoutcrux/directory. - For project-local skills, use
.claude/skillsin Claude Code,.agents/skillsin Codex,.opencode/skillsin OpenCode (which also reads the singular.opencode/skill), and.omp/skillsin OMP. SetCRUX_LOCAL_SKILLS_DIRto that path before following any command below that uses it. - Translate Claude Code tool labels such as
Agent,Read,Write,Bash,WebSearch, andWebFetchto the matching capability in the current session. Codex names its own capabilities; OpenCode uses the lowercase formssubagent,read,edit,shell,websearch, andwebfetch, whereeditcovers bothEditandWrite; OMP usestask,read,edit,write,bash,grep,glob,find,todo, andweb_search(wherereadalso handles URLs andskill://URIs). Do not attempt to invoke the Claude Code labels as literal commands on another host. - Install the generated role agents before delegating:
install-codex-agentsin Codex,install-opencode-agentsin OpenCode,install-omp-agentsin OMP. Codex names themcrux_architect,crux_brainstormer,crux_commander,crux_dev_lead,crux_developer,crux_historian,crux_librarian,crux_night_gardener,crux_reviewer, andcrux_wayfinder; OpenCode and OMP use the bare role namesarchitect,brainstormer,commander,dev-lead,developer,historian,librarian,night-gardener,reviewer, andwayfinder(in OMP,scoutmay also be used for reconnaissance alongsidewayfinder). If a required role or capability is unavailable, report that truthfully instead of claiming it ran. - Argument placeholders such as
$adrand$bookbind only in Claude Code. On a host without argument binding they are unset — take the value from the user's phrase. The "Fields OpenCode ignores" section ofOPENCODE_GUIDE.mdnames the invocation-control fields OpenCode ignores. <!-- END GENERATED: runtime-compat -->
Overview
Codex reads custom subagents from .codex/agents/*.toml; it does not consume
Crux's source agent Markdown files. This skill installs the ten namespaced Crux
roles into the active user's personal Codex directory by default:
crux_architect, crux_brainstormer, crux_commander, crux_dev_lead,
crux_developer, crux_historian, crux_librarian,
crux_night_gardener, crux_reviewer, and crux_wayfinder.
The generated files are crux-<role>.toml. Each file pins the role's model and
reasoning effort from crux/catalog/models.yml. It also contains one enabled
skills.config entry for each skill declared in crux/agents/<role>.md.
Those entries use absolute paths to the selected plugin's SKILL.md files.
The installer preserves unrelated agent files. Read-oriented roles default to
Codex's read-only sandbox; writer roles default to workspace-write.
Install
<!-- Provenance: this skill assumes the crux plugin is already installed in
Codex via codex plugin marketplace add bionic-coding/crux then codex plugin add crux@crux (documented in install-docs-skills/references/install-and-upgrade.md). That CLI syntax is
an external Codex contract owned by OpenAI, not by crux — track it against
upstream, don't assume it. Verified 2026-07-09 against the official docs
(https://developers.openai.com/codex/plugins/build) and against the local
codex plugin ... --help for codex-cli 0.144.0, which accept the
owner/repo marketplace source and the PLUGIN@MARKETPLACE positional
(crux@crux) forms. -->
Codex provides this selected skill's absolute SKILL.md path in context. Let
<skill-dir> be its containing directory.
Install for the active user:
uv run <skill-dir>/scripts/install.py
This targets ~/.codex/agents/. Supply the current repository when you also
want the health report to scan for project agents with the same effective name:
uv run <skill-dir>/scripts/install.py --project-context "$PWD"
Use project scope only when the user requests repository-local agents:
uv run <skill-dir>/scripts/install.py --repo-root "$PWD"
--repo-root and --codex-home are mutually exclusive. --codex-home <path>
sets the personal target to <path>/agents. It supports isolated tests and
explicit alternate installations. Codex discovery from an alternate home
remains unverified until that exact client and path pass the fresh-session procedure in
references/fresh-session-verification.md.
Check health without writing
uv run <skill-dir>/scripts/install.py --check --project-context "$PWD"
--check prints JSON and does not create the target. Its exit status is 0
when drift.status and installed.status are clean and the shadow scan has
no findings. It returns 1 for managed drift, installed-state findings, or
shadow findings. It returns 2 for a configuration or environment error.
The stable health report uses these terms:
scope:personalorproject.target: the resolved agent directory.plugin:rootandversionfor the selected Crux plugin.roles: the sorted canonical expectations. Each record containsrole,name,model,model_reasoning_effort,declared_skills, andresolved_skills.installed: parsed managed TOML state. It containsstatus(cleanorfindings) and a sortedrolesarray. Each installed role containsrole,file,status,model,model_reasoning_effort, andskill_bindings. Role status isinstalled,missing,unsafe, ormalformed.skill_bindings: each installed role's binding comparison. Every binding containsskill,expected_path,installed_path, andstatus. Binding status isenabled,disabled, ormissing.drift:status(cleanordrift) plusadded,changed, andremoved.shadows:status(unverified,clean, orfindings) plusproject_context,roles,malformed, andunsafe.runtime:status,client_version, andreason. The current runtime status isunverified, the client version isnull, and the reason isfresh-session host evidence has not been recorded.
A completed install adds written and removed to the report. Repeating an
unchanged install returns an empty written list and does not rewrite files.
roles always describes the selected plugin's canonical configuration.
installed.roles describes what the health check parsed from managed files.
Refresh managed files
A later run refuses to replace a changed managed file or remove a stale managed
file. Review the reported changed and removed lists, then refresh:
uv run <skill-dir>/scripts/install.py --force --project-context "$PWD"
Plugin relocation changes the absolute skill paths and therefore appears as
managed drift. Refresh with --force after you verify the new plugin root.
The installer preserves unrelated files and refuses managed symlink leaves.
It also refuses any target or managed leaf that resolves outside the selected
personal or project root.
Understand shadowing and runtime limits
--project-context <repo> scans <repo>/.codex/agents/*.toml by the effective
TOML name, regardless of filename. It reports matching crux_* roles,
malformed TOML, and unsafe symlinks without changing the repository. Without
--project-context, shadows.status is unverified.
Start a new Codex thread after installation so Codex can discover the agents.
Ask Codex to spawn a namespaced role such as crux_reviewer or
crux_developer. Static health separates canonical expectations in roles
from parsed managed files in installed.roles. It does not prove host
discovery, effective model settings, skill loading, or workflow behavior.
Runtime stays unverified unless the selected Codex version has a recorded
pass and the health reporter consumes that evidence.
Skill configuration controls availability and enablement. It does not grant tools, credentials, sandbox access, or eager instruction loading. Parent-session permission overrides and Codex's delegation-depth limits still apply.
Verification
- [ ] The selected target contains the ten generated
crux-*.tomlfiles. - [ ] Existing non-Crux agent files remain unchanged.
- [ ] Every role record contains the expected model, effort, and declared skills.
- [ ] Every
resolved_skillsentry points to the selected plugin'sSKILL.md. - [ ]
installed.statusiscleanand every installed role has statusinstalled. - [ ] Installed models, efforts, and skill bindings match the canonical role.
- [ ]
drift.statusiscleanafter installation. - [ ] Shadow findings were reviewed, or
shadows.statusis recorded asunverifiedbecause no project context was supplied. - [ ]
runtime.statusis reported asunverifieduntil fresh-session host evidence exists.
Guardrails
- Do not hand-edit generated
crux-*.tomlfiles. Changecrux/agents/*.mdin the Crux source, regenerate, and refresh intentionally. - Do not use
--forcebefore reviewing changed and stale managed files. - Do not treat a role's self-report as evidence of its effective model, effort, or loaded skills. Use host-observed evidence.
- Codex parent-session permission overrides can be broader than a role's default sandbox. The role prompt remains binding even when that occurs.
04 同仓库更多 Skills
whiteboarding
Explore an idea through docs-informed dialogue before committing to a design. Capture the exploration for later filing as a brief.
verify-code-docs
Check generated code documentation against source and report drift without regenerating it.
transition-observation
Apply a human disposition to an observation's lifecycle state without changing its claim or body.
transition-invariant
Ratify, reject, or retire an invariant on human direction. Update lifecycle metadata without changing the invariant's body.
transition-decision
Apply a human ratify, reject, or defer verdict to a recovered decision candidate; ratification creates a Proposed ADR or observation.
transition-brief
Publish or abandon a draft brief, updating lifecycle metadata and indexes without changing its body.