AI-DLC 2.11.0 can stop a Codex CLI workflow before code generation so a developer can read the proposed plan and approve it. This guide follows the October 8, 2026 v2.11.0 release and its versioned Codex CLI, workflow profile and Plan Approval instructions. BIG CHANGE inspected those documents and the tagged command reference. We did not install or run AI-DLC; every step below is documentation-only.

The intended reader is a developer with a Git project who wants to inspect a code plan before an AI coding assistant generates files. The expected result is a Plan Approval question that names the plan, lets the developer request changes, and leaves the build waiting until the developer answers. AI-DLC still has later checks; this gate is specifically about the code plan.

Before you start

The tagged Codex guide requires Codex CLI 0.145.0 or newer, a Git repository for project hooks, and a configured model provider. The native AI-DLC release does not require Bun or Node.js. Use a project whose code and plan you are authorized to send to your configured model provider. Review the provider's data handling and billing terms separately; the AI-DLC repository does not state a single provider usage price for this workflow.

Have a concrete development task ready as the input. This walkthrough chooses the Feature profile because v2.11.0 documents Plan Approval as on for Feature. Express and Proof of concept start with Plan Approval off, though a person can request a review of a particular plan. The profile matters more than a generic expectation that every AI-DLC run will pause.

1. Install and verify the pinned release

On macOS, Linux or WSL, the v2.11.0 release gives this version-specific installer command:

Terminal
curl -fsSL https://github.com/awslabs/aidlc-workflows/releases/download/v2.11.0/install.sh | sh -s -- --version 2.11.0

The release also provides a version-specific Windows installer for PowerShell. Inspect the installer and choose the path appropriate for your machine before running it. Then check the installed version and environment from your project:

Terminal
aidlc --version
aidlc doctor
codex --version

Expect aidlc --version to report 2.11.0. aidlc doctor reports configuration and runtime problems, while codex --version lets you check the minimum Codex CLI version. If the installed version is different, stop here and use the v2.11.0 release's installation or refresh instructions; the steps below are pinned to that release.

2. Configure Codex and trust the project hooks

From the Git project root, use the tagged Codex setup path:

Terminal
aidlc config --harness codex
aidlc doctor
codex

Codex asks whether to trust the project hooks. Review the project and the generated hooks before choosing Trust all and continue. The tagged guide says an already-dismissed dialog can be reopened with /hooks, then t and Esc. Run $aidlc --doctor in Codex after trust. If hooks are not running, follow the harness guide's trust recovery; a successful installer alone does not establish that the project's hooks are active. The model provider and its credentials are configured in Codex's user-level settings, not supplied by AI-DLC.

3. Start a Feature workflow and inspect its settings

First run $aidlc --status in Codex and check that no workflow is active. The tagged command reference says a bare scope command carries on with existing work when a workflow is active. Use a project with no active workflow for this walkthrough.

In that configured Codex project, type $aidlc feature and answer its request for the task you want to build. The input should describe the feature and its constraints; the eventual plan is generated from that work. Before the code plan is built, inspect the effective controls using the v2.11.0 command reference:

Text
$aidlc --status
$aidlc config get plan-approval
$aidlc config get guard-policy

Look for Plan Approval on and its stated source. If it is off for this intent, $aidlc --plan-approval on turns the question on for the next plan. A machine-level switch can force it off, and a team memory rule can require it on; the status line identifies the effective value. For this walkthrough, set Guard Policy to strict with $aidlc --guard-policy strict if you also want an edited, already-approved plan or its test instructions to require another approval. Plan Approval on controls the first question; Guard Policy controls what happens after an approved plan changes.

4. Review the code plan at the gate

Continue the workflow until Code Generation has a plan ready. With Plan Approval on, the v2.11.0 engine presents the plan's summary and path, including choices to Approve Plan, Request Changes, or I'll edit the files. Open the named code-generation-plan.md and read the proposed files, sequence and test instructions. Review any commands, access to project data and actions that might change the repository before approving.

Choose Request Changes if the plan needs a different implementation or test. If you edit the files yourself, use the engine's I'll edit the files path rather than treating an edit as an approval. Only your answer authorizes the plan; a model cannot approve it for you. With the gate on, code generation waits for that answer. The release notes say a review, setting, commit or another permitted request can proceed while the build waits.

5. Approve, check the receipt and handle a changed plan

When the plan is acceptable, answer Approve Plan in the open question. The engine records the approval against that plan and resumes the build through its normal next flow. An unchanged approved plan is remembered across chat compaction or parking, according to the release notes. The tagged command reference documents read-only aidlc engine audit history for inspecting the recorded timeline, and $aidlc --status shows the workflow's position. These records are the success check alongside the gate visibly appearing before generated code.

If the plan or its test instructions change before the build, strict Guard Policy asks for approval again. Under relaxed or off policy, the change is reported and recorded but the workflow can continue without a mandatory new approval. The tagged docs also distinguish unrelated source files moving after approval: that movement is reported, while plan approval remains about the plan and test instructions. The person can say “go back to the approved plan” to restore the earlier plan before the build. An unchanged plan should not prompt a second time merely because the chat was compacted.

If the pause does not appear

First read $aidlc --status and $aidlc config get plan-approval. Check the selected scope, the effective setting and its source. Express and Proof of concept default to off; enable Plan Approval for that intent or start a Feature workflow if its full lifecycle fits the task. If configuration or hooks appear broken, run aidlc doctor and follow the Codex harness recovery. Check for a version mismatch before changing an active project runtime. Do not assume a missing question proves approval was recorded: with the setting off, AI-DLC writes a PLAN_APPROVAL_SKIPPED row, which the tagged docs explicitly distinguish from a person's approval.

The big change

  • AI-DLC 2.11.0 places the plan question in its engine, which records the decision and keeps an unchanged approved plan through a parked or compacted session.
  • For a Codex CLI Feature run, the developer can check Plan Approval's effective setting, read the plan before code generation and request changes at the gate.
  • Reapproval after a plan edit depends on Guard Policy. The developer can choose strict for a renewed stop when the plan or test instructions change.

Sources & further reading