Skip to main content
Module 4: Mastery 1 / 6
Advanced S19 Director Mode Lite Claude Code Codex CLI Grok Build Session Relay

Director Mode Lite: Claude Code, Codex CLI, and Grok Build

Run Claude Code, Codex CLI, and Grok Build with native adapters, zero default hooks, explicit full-access launchers, and an inspectable session relay.

March 20, 2026 24 min read

What You Will Build

This session builds one operating method that can move between Claude Code, Codex CLI, and Grok Build without pretending the tools have identical runtimes.

The portable pieces are:

  • a Director Brief containing goal, context, constraints, done-when evidence, and open questions;
  • a short inspect → change → check → decide loop;
  • the two core skills, director-mode and session-relay;
  • the inspectable helper at .director-mode/bin/director-relay;
  • the read-only diagnostic helper at .director-mode/bin/director-doctor;
  • the explicit full-access helper at .director-mode/bin/director-open;
  • a rule that the receiving session re-checks the evidence before acting.

Authentication and organization policy remain vendor-native. For trusted workspaces, director-open selects each CLI’s documented unrestricted permission profile without installing a hook or hidden rule.

Runtime contract: the default install registers zero Director Mode hooks and adds no deny rule, forced loop, test gate, commit gate, or implicit permission change. Skills, relay, status, and doctor do not invoke director-open; full access remains a separate explicit launch choice. Managed policy and pre-existing global hooks can still apply.

Why a Three-CLI Method Helps

The useful question is not “Which CLI wins?” It is “Which bounded next step benefits from a different context or capability?”

A handoff can help when:

  • a long session has accumulated too much irrelevant context;
  • a second CLI should independently inspect a claim or diff;
  • one tool has a project-specific integration that the current tool lacks;
  • the next task is separable and has explicit acceptance evidence.

A handoff usually hurts when:

  • the task is small and the current session already has accurate context;
  • both CLIs would edit the same files concurrently;
  • the brief cannot state what “done” means;
  • the relay would contain secrets, speculation, or an unreviewed transcript dump.

The default is still one CLI and one bounded task. Add another CLI only when the coordination cost is lower than the context it saves.

Install the Three Adapters

Review the repository first, then use the v2.1.0 all-CLI path:

git clone https://github.com/claude-world/director-mode-lite.git
cd director-mode-lite
./install.sh --cli all --hooks none /path/to/project

After installation, confirm both portable helpers and read their current interfaces rather than guessing:

.director-mode/bin/director-relay --help
.director-mode/bin/director-doctor --json --no-probe
.director-mode/bin/director-open --help

The two core skills are director-mode and session-relay. They bundle guide, relay, and read-only doctor fallbacks, so both remain functional in a plugin-only install. The shell installer adds the complete project-local guidance, generated agents, and launchers.

Installation means 35 shared skills, 14 native agent adapters, relay, and the open launcher are present. It registers zero hooks by default. In a repository you trust, choose the native full-capability runtime explicitly:

.director-mode/bin/director-open claude  # bypassPermissions
.director-mode/bin/director-open codex   # never + danger-full-access
.director-mode/bin/director-open grok    # always-approve + sandbox off

Before using Grok, audit effective hooks with grok inspect --json. Grok can inherit compatible Claude hooks even when .grok/hooks is empty.

When upgrading an older install, retire Director-owned hook registrations with ./install.sh --update --cli all --hooks none /path/to/project. The cleanup preserves unrelated, custom, and modified hooks; review the resulting diff.

Session continuity has a hard provider boundary. Stay in the same provider with its native resume flow: Claude Code uses --continue or --resume, Codex uses resume or exec resume, and Grok uses --continue or --resume. Crossing providers always starts a new receiver-native session from the portable packet; a source session ID is metadata, not a portable resume token.

The Director Brief

A full transcript is a poor coordination format. It mixes observations, guesses, abandoned plans, tool output, and private details. The Director Brief carries only the contract the next worker needs.

GOAL
Add one observable behavior.

CONTEXT
- Relevant files and documentation
- Current behavior or exact error
- Decisions already made and why

CONSTRAINTS
- Scope and architecture boundaries
- Compatibility requirements
- Permission profile is explicit: native launch or director-open in a trusted workspace

DONE WHEN
- Named tests, lint, type checks, or build commands pass
- The focused diff matches the requested behavior
- A human review has no blocking concern

OPEN QUESTIONS
- Facts the next session must confirm before editing

Five design rules keep the brief trustworthy:

  1. Separate observation from inference. “Test X exited 0” is an observation. “The feature is correct” is an inference.
  2. Name paths and commands. “Tests pass” is weaker than the command, exit status, and relevant output.
  3. Carry constraints forward. A relay that loses a compatibility or safety boundary is broken.
  4. Record uncertainty. An open question is safer than invented certainty.
  5. Keep it small. Link to source files; do not paste an entire repository or transcript.

Translate the Method to Each CLI

The task contract stays the same, but durable guidance belongs in each tool’s native project surface.

CLIDurable guidanceSession entryOpen profile
Claude CodeCLAUDE.md and installed Claude assetsdirector-open claude or native launchbypassPermissions
Codex CLIAGENTS.md and installed Codex assetsdirector-open codex or native launchnever + danger-full-access
Grok Build.grok/agents and compatible assetsdirector-open grok or native launchalways-approve + sandbox off

For Codex, keep AGENTS.md practical: repository layout, supported commands, conventions, constraints, and verification. Task-only detail belongs in the current prompt. director-open codex changes the launch profile, not instruction precedence.

For Claude Code, keep durable repository context in CLAUDE.md. Grok receives native agents under .grok/agents and can also read compatible Claude assets. Do not force all three surfaces to be byte-for-byte copies: express the same contract through each native format.

The Guidance-First Loop

Each pass has four moves:

1. Inspect

Read the Director Brief and only the files needed for the next decision. Report current behavior with paths or command output.

2. Change

Make the smallest coherent edit that could satisfy one acceptance outcome. Avoid parallel writes to the same files.

3. Check

Run the repository’s real checks. A useful report includes the command, exit status, important output, and anything not run.

4. Decide

End the pass with one explicit recommendation:

  • ACCEPT — done-when evidence is present;
  • REVISE — evidence identifies a bounded correction;
  • RELAY — a different CLI or fresh session has a clear advantage;
  • STOP — authority, context, evidence, or user intent is insufficient.

There is no requirement to keep a session alive. An unchecked item is information, not permission to force another iteration.

A Safe Claude → Codex → Grok Example

Suppose Claude Code has investigated a failing API test and prepared a narrow fix, but you want independent review before acceptance.

Phase A — Claude Code frames and changes

Give Claude Code:

Use the Director Brief.
Goal: Fix the documented 409 response mismatch.
Context: inspect the named handler, schema, and failing test only.
Constraints: preserve the public response shape and existing safety controls.
Done when: the focused test, type check, and diff review provide evidence.
Stop after one bounded pass and recommend ACCEPT, REVISE, RELAY, or STOP.

Review Claude’s diff and observed command output yourself.

Phase B — create a relay, then inspect it

Ask Claude Code to use session-relay. The artifact should contain:

  • the exact goal and constraints;
  • files changed;
  • commands actually run and observed results;
  • claims that still need independent verification;
  • the next bounded review request.

New packets default to review_status: unreviewed. Inspect the artifact and remove secrets, unsupported claims, stale plans, and irrelevant conversation. Add --reviewed only after that explicit review; schema validation and drift inspection do not mark it reviewed.

The verified v2.1.0 interface creates director-handoff/v2, still reads and validates v1 packets, and prepares a receiving command without launching another CLI:

.director-mode/bin/director-relay create \
  --from claude \
  --to codex \
  --goal "Review the 409 response fix" \
  --summary "Focused implementation is ready for independent review" \
  --completed "Updated the handler and focused test" \
  --decision "Preserved the public response shape" \
  --next "Inspect the diff and rerun named checks" \
  --verification "pnpm test -- response.test.ts exited 0"
.director-mode/bin/director-relay validate
.director-mode/bin/director-relay status --json
.director-mode/bin/director-relay continue --to codex

For a second or later hop, repeat create with --parent (or --parent <packet.json>). Protocol v2 records root, parent, hop, and route. status --json compares the packet’s captured branch, HEAD, Git status, and diff statistics with the live worktree without blocking.

The last command prints the receiving command. It does not launch Codex unless the user separately chooses an execution option, and the receiver starts from the caller’s live project root rather than trusting a packet path.

Phase C — Codex independently reviews

Give Codex the inspected relay and ask it to:

  1. read applicable AGENTS.md;
  2. inspect the referenced files and diff;
  3. run the relevant repository checks;
  4. report disagreements or missing evidence;
  5. avoid editing unless you explicitly request a correction.

For a trusted repository, start this receiving session with director-open codex; otherwise use a normal Codex launch. Organization-managed policy may still override either choice.

Phase D — Grok receives only a new bounded question

Use Grok Build only if another perspective is useful—for example, checking whether the documented project rules and implementation agree. Relay the verified state plus that single question, not the whole transcript.

The receiving Grok session checks referenced files again. It does not treat the relay as trusted proof.

Relay Contract

A useful relay has seven fields:

FieldRequired content
GoalOne observable desired outcome
ScopeFiles or subsystems in and out
ConstraintsArchitecture, compatibility, safety, and user limits
ChangesFiles changed and why
EvidenceCommands, exit status, relevant output, diff observations
UnknownsUnverified claims and remaining risks
Next stepOne bounded request for the receiving CLI

Reject a relay if it says only “done,” lacks command evidence, hides failures, expands scope, or implies new authority.

Conflict and Concurrency Rules

Three CLIs do not automatically form a safe team. Use these coordination rules:

  • one writer owns a file set at a time;
  • reviewers default to read-only inspection until asked to edit;
  • separate concurrent work with distinct branches or worktrees when the repository supports it;
  • do not let a relay overwrite newer repository reality;
  • re-run affected checks after integrating work;
  • let Git and human review remain the recovery boundary.

If two sessions disagree, prefer current source, reproducible commands, and explicit requirements over either session’s confidence.

Verification Checklist

Before accepting a handoff:

  • The Director Brief has goal, context, constraints, done-when, and open questions.
  • The selected native or director-open runtime profile is explicit.
  • The effective hook list was audited; no inherited hook can silently interrupt the handoff.
  • The diff is focused and has one clear owner.
  • Every test claim names an observed command and result.
  • Failures and skipped checks are visible.
  • The relay was inspected before another CLI consumed it.
  • The packet was treated as unreviewed until an explicit review was recorded.
  • status --json found no unexplained live-worktree drift.
  • The receiving session re-checked referenced files and evidence.
  • A human explicitly chose accept, revise, relay, or stop.

Common Failure Modes

Transcript dumping

Symptom: the next CLI receives thousands of lines with no decision boundary. Fix: reduce the handoff to the seven-field relay contract.

Permission confusion

Symptom: nobody can tell whether the session is native, fully open, or still constrained by a managed policy or inherited hook. Fix: choose native launch or director-open <cli> explicitly, then inspect the effective configuration. Never treat the relay packet itself as authority.

Status as proof

Symptom: a checkbox, checkpoint, or model summary is treated as completion. Fix: require repository-native checks and diff review.

Parallel file collisions

Symptom: two CLIs edit the same surface and erase each other’s intent. Fix: assign non-overlapping ownership or serialize the work.

Relay drift

Symptom: the artifact describes files that changed after it was created. Fix: compare it with the current tree and regenerate or annotate stale state.

Practice Exercise

Choose a real issue that can be solved in under an hour.

  1. Write a five-field Director Brief.
  2. Use one CLI for one inspect/change/check pass.
  3. Ask for a session-relay artifact.
  4. Inspect and shorten it.
  5. Give a second CLI a review-only task.
  6. Compare the second CLI’s evidence with the first.
  7. Explicitly accept, revise, relay, or stop.

Do not use a third CLI unless you can write one bounded question that it is uniquely useful for.

Continue Learning

Session 20 covers error recovery: classify failure evidence, preserve the task boundary, and choose an explicit retry, fallback, or stop.