The complete flow for delegating a coding task through Kay or Codex — from current-session readiness through runtime routing, host verification, retry, and deactivation. If you need the task-first docs map, read Start Here first.
Type /sidekick:codex-delegate in the host. Claude and Codex hosts both use the canonical skills/codex-delegate/SKILL.md workflow, with rendered host copies generated from the same source.
The host verifies that the real OpenAI Codex CLI is available, is not Kay's compatibility alias, and supports codex exec --ask-for-approval. Any failure halts activation with a specific repair path.
The host creates the Codex marker under .codex/sessions/<session>, prepares the host session directory, and ensures the project-local .codex/conversations.idx audit ledger can be written.
The host clears any Kay marker, writes active-sidekick=codex, then confirms Codex sidekick mode. The hook layer routes implementation work to Codex until you run /sidekick:codex-stop.
codex.Kay uses its native automation flow. Sidekick keeps the runtime packaged, exposes the delegate/stop skills for host pickers, and preserves a project-local Kay audit ledger. Claude Code and Codex both activate Kay mode through /sidekick:kay-delegate; active Kay mode launches Kay as a child execution runtime through kay exec while the host remains in the planning and verification role.
Run kay --version and kay exec --help. If Kay provider login is missing, run kay login --provider opencode-go --with-api-key.
Run /sidekick:kay-delegate, /sidekick:kay-delegate xiaomi, or /sidekick:kay-delegate ocg, then give the host the task to delegate. Activation clears any Codex marker and writes active-sidekick=kay. The hook surfaces bounded, redacted output with [KAY].
The Kay progress surface emits compact [KAY-SUMMARY] context when a STATUS block appears and preserves lookup metadata in .kay/conversations.idx. Review changed files, test output, and the final task summary before continuing.
When you describe a task, the host converts it into a focused sidekick prompt and delegates through the active runtime:
The host streams bounded sidekick output and checks whether the child runtime completed the requested work:
Error:, Failed:, fatal:, or non-zero exitIf no failure signal is detected, the host still performs the verification pass in Step 4 before reporting success.
Every sidekick result is verified against the original prompt and surrounding repository behavior:
The host checks the diff, touched files, signatures, imports, config, and assumptions.
The host runs the smallest meaningful tests, lint, build, type checks, or runtime checks.
Failures are classified as missed requirement, integration error, regression, wrong logic, syntax error, wrong file, unverified assumption, knowledge gap, misunderstood task, incomplete trial, API failure, or external execution error.
The host presents the result only after verification evidence supports it. Review the changed files, assumptions, and command output before accepting the work.
If something needs adjustment, describe the change in plain language. The host relaunches the active sidekick with focused correction context; there is no need to re-activate.
If host verification finds a failure, the host relaunches or guides the active sidekick. It includes the original task, failure code, evidence, relevant files, constraints, and exact success criteria.
The host repeats verify → relaunch until the result satisfies the original task and no taxonomy failure remains.
Delegation mode persists for the entire session. You can delegate as many tasks as needed without re-running activation. To return to direct host behavior, stop the active sidekick:
This removes the current-session marker and clears active-sidekick when it still points at the stopped sidekick. The project audit ledger is preserved.