| Phase | 7 — Core engine |
| Status | Not started |
| Depends on | 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 |
| Size | M |
| Drop-in critical | partial |
Port codex-core-api and complete the wiring: assemble all managers (MCP, skills,
plugins, hooks, models, environment, memories, guardian, extensions) into the Codex
engine and expose the stable public facade other binaries (app-server, exec,
mcp-server, TUI) consume.
reference-codex/codex-rs/core-api/src/(re-exports + facade traits).core/src/manager construction insession/mod.rs;codex-core-plugins,codex-core-skillsintegration points.
core-apipublic surface: re-exportOp,EventMsg, thread lifecycle traits, and theCodexconstructor inputs so downstream crates depend on a stable facade rather thancoreinternals.- Manager assembly: construct and inject
McpManager(21),SkillsManager(23),PluginsManager(22), hooks engine (24),ModelsManager(07), environment manager (10), memories (26), guardian/extensions (26) intoCodexSpawnArgs. - Lifecycle ordering: initialize managers in the same order Codex does (so e.g. skills/plugins are available before the first turn), with the same error handling if a manager fails to start.
thread-manager-sample-style end-to-end smoke path for integration testing.
- A full engine can be constructed and run a turn end-to-end (with mocks for the model) producing Codex-equivalent events/rollout.
- Manager init order + failure handling matches Codex (e.g. a failing MCP server degrades the same way).
core-apiexposes everything app-server/exec/tui need without leakingcoreinternals.
- This is the integration capstone of Phase 7; bugs here surface as cross-cutting differential failures. Land it behind a solid integration test.
- The transports that expose the engine (Phase 8).