Codex and Claude Code: My Multi-Session AI Coding Workflow

While rebuilding my portfolio, I ran several AI sessions at once. One handled the homepage and design system, another worked on bilingual articles and images, and a separate task reviewed navigation and translations. I did not want every task to wait for one conversation. But telling the agents to collaborate and avoid overlap was not a complete working agreement.

This is my UIUX Lead perspective on the workflow I adjusted in that project: ownership, rules, skills and a review loop that can actually finish. The examples come from this portfolio. The Codex and Claude Code comparison is based on official documentation checked on August 27, 2026, not a claim that I tested every feature in both tools.

When I split work across sessions

I did not split the project into a React agent and a CSS agent. Homepage layout and article writing could progress independently, but two tasks changing the same shared component needed coordination first. Useful parallel tasks had their own deliverable, such as an article translation, a set of correctly matched images or a read-only navigation review.

For a one-line correction, more sessions add explanation and handoff work. I would start with one implementation task and one narrowly scoped reviewer, then add another task only when there is genuinely independent work to do.

What I mean by loop engineering

I use loop engineering here to describe my working method, not an official Codex or Claude Code feature. I mean designing how one round of work feeds the next: its input, decision owner, feedback destination and stopping condition. It is not an instruction to let agents review each other forever.

Assign files and decisions, not just job titles

Early coordination messages proposed different integration owners. If several sessions each expect to make the final commit, asking them not to touch each other's work is not enough. I settled on one integration owner. Other tasks returned their ready files and checks instead of pushing independently.

This table is an ownership agreement, not a file lock. A cross-scope change needs the exact file named and ownership transferred first. A new task reads the current assignment instead of guessing who is still editing from an older conversation.

Agree on the shared interface before implementation

The four-card related-reading section is a concrete example. I wanted both articles and work pages to recommend content and link back to the relevant category. That did not call for two separate card systems. The shared component owner first agreed on inputs such as currentKey, entries, locale and the category link. The writing task wired the Blog route while the homepage task wired the Work route.

My UIUX decisions were relevance, no self-recommendation, language consistency and a clear distinction between returning home and returning to a category. The implementation owners then agreed on the data and component boundary. Each task was implementing the same behavior, not its own interpretation of a screenshot.

AGENTS.md and CLAUDE.md need one shared rule source

Codex reads AGENTS.md for project guidance. Claude Code uses CLAUDE.md and documents importing an existing AGENTS.md. I would maintain one shared rule source, with separate tool-specific additions. This is a setup recommendation for my next project, not a claim that both configurations are installed in this portfolio. Codex project instructions · Claude Code instruction imports

For example, CLAUDE.md can reference @AGENTS.md. The shared rules should cover the following, without creating another long and conflicting instruction set.

• Which project rules, architecture, design system and task records to read first.
• Allowed files, shared component responsibilities and how to request a scope change.
• The branch, local environment, preview location, build output and who can start or rebuild it.
• Acceptance conditions, relevant QA, publishing authority and stopping conditions.
• Secrets stay out of conversations, records and public assets. Ignore rules are not access control and do not remove already tracked secrets.

What belongs in a skill

I have already turned recurring UIUX reminders into personal skills, including reusing existing components and variables, and checking color, radius and spacing tokens. I do not directly commit those personal versions into the company repository. A team version should be reviewed and adapted for that project.

For multi-session work, I would first package three procedures: checking scope before claiming a task, reporting reproducible review findings, and preparing files and QA for handoff. Each skill needs a trigger, inputs, steps, an output and a blocked-state response. These are proposed reusable procedures, not three tools I claim to have already built.

Both tools support skills. A skill supplies instructions, not mutual exclusion or a guarantee that tests pass. Enforced boundaries still need appropriate permissions, hooks or CI. Nothing in this workflow requires disabling safety approvals. Codex skills · Claude Code skills and hooks

What Codex and Claude Code already provide

This is a feature summary from the official documentation, not a performance comparison. Availability and controls can differ by version, account and interface.

• Codex: current releases provide subagents. You can explicitly request independent delegated work and collect its results. Applicable project or skill instructions can also request delegation. Official subagent documentation
• Claude Code: provides subagents and agent teams for shared tasks and coordination. Agent teams are currently experimental, disabled by default, and require explicit configuration. Official agent-team documentation
• Worktrees: both tools support separate Git checkouts for file isolation. That does not decide component ownership or resolve conflicting product decisions for me. Codex worktrees · Claude Code worktrees

I do not need to build a large multi-agent system before delegating useful work. I can start with the tool's existing capabilities and add project agreements. If both Codex and Claude Code participate, I do not assume automatic shared conversation state. The common handoff record and exact revision remain the reference.

Review the changed behavior, then verify the exact version

One article navigation issue was very specific: two delivery-option headings shared a row on desktop, but the contents highlight favored the later heading. The reviewer returned the cause and reproducible conditions to the article owner. That was actionable in a way that asking for another general UX review was not.

Adding related reading also changed a test assumption. Its own headings were not part of the article contents list, yet the original check inspected every heading in the article. The fix scoped that check to the reading body rather than removing useful semantic headings to satisfy an outdated assertion.

When I asked for verification once, I meant not having every session repeat the same completed checks. I did not mean skipping verification after a fix. A task runs relevant scoped QA, then the integrator checks the version being shipped. If a failure requires a correction, the affected check runs again.

A passing build did not settle whether the UI was right. This portfolio also needed corrected project-image matches and a clear distinction between home and category returns. Those required content and interaction judgment. An unavailable browser check stays unverified instead of being replaced by a type-check result.

Freeze a ready batch and let one owner integrate it

Brand Center screenshots, work-page images and Traditional Chinese translations were separate batches. I did not want finished translations to wait indefinitely for another image set. Each batch listed exact files and QA. After reporting READY, its owner stopped editing while the integrator captured a snapshot. New requests remained valid, but belonged to the next batch.

This matters especially in a shared local folder. Different branch names do not create isolated copies of the same files. We also assigned control of .next builds, the Git index and the preview, so one task would not validate another task's unfinished output. A team repository should retain its branch, PR and code-review process. My authorization to push this personal portfolio to main is not a default for company projects.

A starter brief I would use for the next project

This starter brief is adapted from the experience. Replace its goal, paths and acceptance conditions with your project's. It is a communication template, not a command that configures permissions or enables agent teams.

Goal: Add four relevant reading recommendations to article and work pages.
Start by reading the project rules, current implementation and uncommitted diff.

Before editing, propose the smallest useful division of work.
For every task, name its owner, allowed files, excluded files and acceptance checks.
Agree on the shared recommendation component's input before changing either page.
Keep one owner for the shared registry, PLAN.md, HANDOFF.md and final integration.
Use separate worktrees when file ownership cannot safely be separated.

Review findings must include reproduction steps and the inspected version.
Run only checks relevant to the changed scope, then one integration check.
If a check fails, fix the cause and rerun the affected check.
Report missing permission, unavailable tools and unresolved decisions without guessing.
When ready, send exact files, QA results and remaining limits, then freeze them.
Do not stage another task's changes or push without the agreed authorization.
Stop at the agreed acceptance conditions. New requests go into the next batch.

My handoff checklist

• The task names the user problem, acceptance conditions and what is out of scope.
• Every changed file has an owner. Shared interfaces have an agreed shape before callers change.
• The handoff identifies the branch or base revision, exact paths and the frozen snapshot or file hashes.
• Existing components, tokens and localized copy have been reused where appropriate.
• Review findings say what happened, how to reproduce it and which version was inspected.
• Relevant desktop, mobile, keyboard and content-language checks are recorded as passed, failed or not run.
• A build or type check is not described as visual acceptance. A tool blocker is recorded without a workaround.
• Images match the case. Publication permission and required masking are checked separately from code quality.
• Only the integration owner stages the approved batch. Unrelated and unfinished changes stay untouched.
• The final record distinguishes local completion, a pushed commit and a verified live deployment.

Common questions

Do I need a multi-session skill first?

No particular skill is a prerequisite. Start with the tool's delegation support and a clear scope. Package repeated handoffs or UIUX checks into a skill when they become reusable. A skill does not replace file isolation or publication permissions.

Can sessions use the same local folder?

Yes, with explicit ownership of files, shared builds and Git operations. We used that arrangement here, but it did not remove the risk. If several tasks need the same area, prefer isolated worktrees and a coordinated merge and verification step.

When should the loop stop?

Stop when acceptance conditions are met, relevant checks are complete and the handoff is recorded. Repeated failure, missing permission or a human decision also calls for stopping and reporting. Agree on a round or time limit before another review becomes open-ended work.

What I would improve next

What I established here was a way to continue, inspect and deliver parallel work in separate batches. I have not measured hours saved. Next time I can record integration waiting time, reopened findings and repeated checks, then decide which steps are worth automating.

For the rules behind a single task, I also wrote how I turned prompt rules into an AI delivery system. To see the design work itself, continue with my ReactJS workflow for the Ogloba website. This article covers how those tasks work together, not another rule system to maintain.