# Configure AI-DLC 2.11.0 to pause for code-plan approval

> A version-pinned, documentation-only guide to enabling and checking AI-DLC 2.11.0's human plan-approval gate before code generation.

By BIG CHANGE Editorial

Published: 2026-10-15T18:54:16.360Z
Updated: 2026-10-15T18:54:16.360Z
Canonical: https://bigchange.ai/blog/aidlc-2-11-plan-approval-guide

![Conceptual charcoal illustration of one developer reading abstract plan-like lines on an unbranded desktop monitor while the keyboard sits untouched.](https://bigchange.ai/api/media/file/aidlc-human-plan-review-hero-v1.png)
AI-generated conceptual illustration by BIG CHANGE; no actual AI-DLC interface, user session or observed test result is depicted.

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](https://github.com/awslabs/aidlc-workflows/releases/tag/v2.11.0) and its versioned [Codex CLI](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md), [workflow profile](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/workflow-profiles.md) and [Plan Approval](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/13-customization.md#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](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md) 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:

```bash
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](https://github.com/awslabs/aidlc-workflows/releases/tag/v2.11.0) 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:

```bash
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](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md#install):

```bash
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](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/12-cli-commands.md) 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](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/12-cli-commands.md):

```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](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/12-cli-commands.md#read-earlier-questions-and-the-audit-timeline) 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](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md#refresh-and-version-skew). 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

- [AI-DLC 2.11.0 release](https://github.com/awslabs/aidlc-workflows/releases/tag/v2.11.0) — dated release, pinned installers and the stated Plan Approval behavior. Release notes describe the feature; they do not demonstrate this guide was run by BIG CHANGE.
- [Codex CLI guide at v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md) — Codex version, Git and provider prerequisites, project configuration, hook trust and invocation.
- [Workflow profiles at v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/workflow-profiles.md) — profile defaults and the Feature versus Express/Proof of concept distinction.
- [Plan Approval and Guard Policy at v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/13-customization.md#plan-approval) — the first approval gate, skipped records and behavior when an approved plan changes.
- [Command reference at v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/12-cli-commands.md) — status, configuration and audit-history commands.

## Sources

- [AI-DLC 2.11.0 release](https://github.com/awslabs/aidlc-workflows/releases/tag/v2.11.0) — Pinned installers and project description of engine Plan Approval; no BIG CHANGE execution.
- [AI-DLC README at v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/README.md) — Harness and configuration overview in the October 8 release tag. Generic latest installer intentionally not used.
- [AI-DLC Codex CLI guide at v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/harnesses/codex-cli.md) — Codex prerequisites, project setup, hook trust and version-skew recovery in the October 8 release tag.
- [AI-DLC workflow profiles at v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/workflow-profiles.md) — Feature, Express and Proof-of-concept scope behavior and approval defaults in the October 8 release tag.
- [AI-DLC Plan Approval and Guard Policy at v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/13-customization.md) — Plan question, skipped receipt, changed-plan and test-instruction reapproval behavior in the October 8 release tag.
- [AI-DLC CLI command reference at v2.11.0](https://github.com/awslabs/aidlc-workflows/blob/v2.11.0/docs/guide/12-cli-commands.md) — Version, status, config and audit-history commands in the October 8 release tag; no commands run by BIG CHANGE.