Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add instructions/zake-cn/codex_lead_cc/agents-mdgit clone --depth 1 https://github.com/zake-cn/codex_lead_ccWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00871 | $0.00871 |
| Opus 5 | $0.00436 | $0.00436 |
| Sonnet 5 | $0.00174 | $0.00174 |
| Haiku 4.5 | $0.00087 | $0.00087 |
Grade A, and why
codex_lead_cc AGENTS.md scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 140 lines — stays where its author put it; the contents beside it link to each section on GitHub.
codex_lead_cc (project docs)
Documentation only. The actual supervisor rules Codex loads are written to
CLAUDE.md,AGENTS.md, andMEMORY.mdin supervisor_home.
Final Architecture
User starts codex_lead_cc in a real project directory
-> wrapper creates supervisor_home and session
-> wrapper captures local Claude Code env
-> wrapper starts one CC Bridge process
-> bridge starts one long-lived Claude Code PTY with cwd = real project
-> wrapper starts Codex with cwd = supervisor_home
-> Codex uses cc-send / cc-input / cc-status
Claude Code is the only process that enters the real project directory.
Main Commands
codex_lead_cc cc-send "prompt"
codex_lead_cc cc-send <<'EOF'
multi-line prompt
EOF
codex_lead_cc cc-input --key 1
codex_lead_cc cc-status
Do not use MCP, subagents, delegate, submit, daemon, workers, queues, TaskFile, OperationRequest, TaskContract, or PermissionContract in the main path.
File IPC
Each session owns:
session_dir/
bridge/
inbox/
streams/
results/
state.json
bridge.log
cc-send and cc-input create request files in bridge/inbox, wait for
bridge/results/<request_id>.json, and then print the final clean output.
Intermediate PTY output is hidden by default; --stream tails the clean debug
stream when explicitly requested.
cc-status only reads bridge/state.json.
Session Isolation
Bridge location comes from the current Codex process environment:
CODEX_LEAD_CC_SESSION_ID
CODEX_LEAD_CC_SESSION_FILE
CODEX_LEAD_CC_BRIDGE_DIR
CODEX_LEAD_CC_BRIDGE_STATE
CODEX_LEAD_CC_BIN
No global recent-session guessing. No active_session main path.
Completion
<<<CODEX_LEAD_CC_DONE>>> is auxiliary only.
Main completion:
if seen_done_marker:
completed
else if permission_prompt_detected:
needs_permission
else if submitted_at + submit_grace_ms passed
&& effective_output_seen === false:
not_submitted
else if:
now - last_output_at >= quiet_ms
&& spinner_detected === false
&& permission_prompt_detected === false
&& now - round_started_at >= min_run_ms
&& effective_output_seen === true:
completed
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 140 lines · 871 tokens per session scan A 186a1ad4b378
codex_lead_cc AGENTS.md is an instructions file published in the GitHub repository zake-cn/codex_lead_cc (23 stars, last pushed 2mo ago), licensed Apache-2.0. It adds 871 tokens to every session, about $0.0044 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other instructions, from other repositories
vscode buildNext.instructions.md
Working notes and architecture documentation for the new esbuild-based build system in build/next. Use when making changes to the new build pipeline (transpile/bundle commands, NLS plugin, source-map handling, resource copying, or self-hosting watch tasks).
spec-kit AGENTS.md
AGENTS.md instructions for github/spec-kit, covering agents.md, about spec kit and specify, quickstart — add a new integration in 5 steps, integration architecture and integrationmanifest — file tracking.
codex AGENTS.md
AGENTS.md instructions for openai/codex, covering rust/codex-rs, the codex-core crate, code review rules, crate api surface and model visible context.
langchain AGENTS.md
AGENTS.md instructions for langchain-ai/langchain, covering global development guidelines for the langchain monorepo, corridor security analysis, project architecture and context, monorepo structure and development tools & commands.
vscode oss-third-party-notices.instructions.md
Instructions for microsoft/vscode, covering vs code oss third-party-notices pipeline, architecture, pipeline flow in ci, applying the notice (cutover) and fallback chain (never fail the build).
next.js AGENTS.md
Instructions for vercel/next.js, covering next.js development guide, codebase structure, monorepo overview, core package: packages/next and other important packages.