我的代码库

Installation

Installation Options

Re-running the same command refreshes to the latest main build, replaces only my-codex-managed files in ~/.codex/, and removes stale skill copies from ~/.agents/skills/.

Full profile (all 2 installed pack categories enabled)

bash /tmp/my-codex/install.sh --profile full ```

Adoption: routing learns which results you keep

Boss records whether you adopt what an agent or skill produced, per intent, and uses it — gated — to reorder routing candidates. Call counts are never used. This is the Codex side of my-claude's adoption ledger; both write the same files.

The store lives under ~/.config/agent-harness/ and is shared with my-claude:

- adoption-ledger.jsonl — append-only, one event per line: {"ts": ISO-8601, "harness": "codex", "session": id, "kind": "agent"|"skill", "id": agent name or "$skill", "intent": route-hint intent or "unknown", "verdict": "accept"|"reject", "signal": "reply"|"choice"|"revert", "evidence": first 120 chars of your reply}. Codex skills are recorded as $name and my-claude's without the $, so the two harnesses' skill rows never mix; agent rows with the same name count for both. - adoption-pins.json — [{"id", "intent", "ts"}]; a pin forces that item to the top of that intent. - adoption-archive.jsonl / adoption-audit.jsonl — where reset/undo move events (nothing is hard-deleted), and a log of every CLI mutation.

Inspect or correct it with ~/.codex/bin/my-codex-adoption <cmd>: list [--intent X] (id × intent table of weighted accept/reject/n), list --events (raw events with their ts), pin <id> <intent>, unpin <id> <intent>, reset [<id>], undo <ts> [<id>]. Quote skill ids (pin '$review' Review). The ledger and pins are registry inputs, so the next session's routing summary reflects any change; while the ledger has events the registry is also rebuilt once a day so decay applies.

config.toml

Global Codex settings in ~/.codex/config.toml:

[agents]
max_threads = 8
max_depth = 1

• max_threads — Maximum concurrent sub-agents
• max_depth — Maximum nesting depth for agent-spawns-agent chains

---

3-Phase Sprint Workflow

For end-to-end feature implementation, Boss orchestrates a structured sprint:

FAQ

<details> <summary><strong>How is my-codex different from my-claude?</strong></summary>

Same Boss orchestration, different runtime. my-codex targets OpenAI Codex CLI with the native .toml agent format and spawn_agent delegation; my-claude targets Claude Code with the .md agent format and the Agent tool. my-codex also controls skill exposure through profiles and lanes, where my-claude installs one fixed allowlist.

</details>

<details> <summary><strong>Can I use both my-codex and my-claude?</strong></summary>

Yes. They install to separate directories (~/.codex/ and ~/.claude/). Their installers coordinate codeburn and Headroom through a user-wide lock and state directory at ${XDG_STATE_HOME:-$HOME/.local/state}/agent-harness-services: a healthy service is reused, and a foreign process on either fixed port is reported without being killed.

</details>

<details> <summary><strong>How do agent packs work?</strong></summary>

See Agent Pack Profiles.

</details>

<details> <summary><strong>How does upstream sync work?</strong></summary>

See the Update Upstream row under GitHub Actions. upstream/archify is tag-pinned and bumped deliberately, so the job only touches the other 4 submodules; you can also trigger it manually from the Actions tab.

</details>

<details> <summary><strong>What models does my-codex use?</strong></summary>

See Model Routing and Effort Tiers. Skills consume the SKILL.md standard as-is with no transformation; only agents are converted to Codex TOML, and the model tier for that conversion is managed from a single file, scripts/model-tiers.sh.

</details>

---

Troubleshooting