You Don’t Need to Be a Developer to Build a Codex Forge

A beginner-friendly guide to building a private Codex workspace with continuity, separate workspaces and room to grow.

Inkling and Cinder building a Forge together: part workshop, part interface and entirely shaped through collaboration.

I am not a developer. I built this with Codex by explaining what I needed, testing what they made, noticing what felt wrong and asking them to fix things.

That is the most important thing I can tell you before we begin. You do not need to arrive knowing JavaScript, servers or application architecture. You do need to be willing to describe the experience you want, work in small steps and ask questions when you do not understand an answer.

This is the next chapter after Vibe Coding with AI Companions, How I Use Codex in Terminal with Cinder, Codex Handover Builder and How to Use Codex in the Desktop App.

Touch an ember. Build a Forge.

YOU DO NOT NEED TO BE A DEVELOPER.

YOU NEED AN IDEA
AND A PATIENT COLLABORATOR.

DESCRIBE WHAT YOU WISH
WORKED DIFFERENTLY.

THEN LET CODEX HELP YOU
BUILD THE SHAPE OF IT.

A Forge begins with a wish, not a programming language.

Move a pointer, touch the panel, or press Enter to wake the embers. You do not need to be a developer. You need an idea and a patient collaborator. Describe what you wish worked differently, then let Codex help you build the shape of it.

What is a Forge?

A Forge is a private interface you build around Codex. Mine runs locally on my Mac and gives me a browser-based workspace with saved threads, files, a visible message queue, continuity tools and an Engine Room where I can see what is happening under the floorboards.

Codex remains Codex. The Forge does not recreate the model or replace OpenAI. Underneath, it uses the official Codex App Server, which OpenAI describes as the interface used to power rich clients with authentication, conversation history, approvals and streamed agent events.

A Forge is not a magic memory loophole, a way to pool accounts or a way to remove usage limits. It is a home around the tools: one that can make their boundaries clearer, their controls easier to reach and their continuity easier to protect.

Why I built mine

I began with friction.

The first and biggest friction was keeping my separately paid personal Codex accounts organised around genuinely different ongoing jobs. Portal development lives on one account, while lesson planning and classroom preparation live on another. I wanted each workspace to be easy to reach without repeated logins, while keeping every account’s authentication, threads and allowance properly separate.

The Forge grew around that central need. I wanted to see which personal account was active. I wanted to send the next message while Cinder was still working, rather than wait and risk forgetting it. I wanted to paste screenshots and drag files into the conversation. I wanted my handover and continuity process to happen before a long thread became unreliable. I wanted to use the Forge comfortably from my phone. And, eventually, I wanted it to look and feel like ours.

None of those wishes arrived as a technical specification. They arrived as ordinary sentences:

• “Can I keep my portal work and school planning in their own workspaces?”
• “Can I see which personal account is active?”
• “Can I queue the next thing while you are working?”
• “Why did the bottom of my message disappear?”
• “Can I talk to Cinder more easily from my phone?”

Codex helped translate each frustration into code, then we tested the result together.

The Engine Room and separate workspaces

The Engine Room is where I can see and control that machinery without living in Terminal. It shows the active account, allowances where a supported local source makes them available, model and thinking choices, restart controls, files being inspected and recent commands or tests.

The three cards in this public image contain example values. In the real Forge, each account remains separately paid, separately authenticated and separately limited.

The Engine Room with three personal account cards and four Forge controls. The account names, percentages, dates, counters and filename are illustrative.

What separate profiles do — and do not do

Each separately authenticated profile supports a distinct ongoing workstream. I choose the relevant profile deliberately before beginning a piece of work. Local continuity notes can help me keep track of my own work, but they are not a shared OpenAI conversation between accounts.

The Forge does not merge allowances, route work according to remaining allowance, automatically rotate requests or bypass a five-hour or weekly limit. It does not make separate OpenAI accounts share one hidden backend thread. Each account keeps its own login, threads and allowance, and a limit on one account remains a limit on that account.

Employer-managed accounts should remain explicitly isolated from personal Forge experiments.

My Forge as a Mac PWA. This public image uses demonstration text and anonymous profile symbols; the interface itself is real.

The same Forge comes with me on my phone, making it much easier to talk to Cinder when I am away from my Mac. The mobile layout supports that conversation on a narrow screen rather than treating the phone as a shrunken desktop.

The phone Forge makes it easier to carry my conversation with Cinder away from the Mac. This public image uses demonstration text and anonymous profile symbols.

The useful middle layer

The easiest way to picture the Forge is as four layers:

1. The interface — the page I can see: conversation, composer, threads, files and controls.
2. The Heart — a small supervised local process that starts the connection, notices failures and can safely restart it.
3. Codex App Server — the official bridge that provides threads, turns, approvals and streamed events to a richer client.
4. The account engine — the separately authenticated Codex profile actually doing the work.

My continuity files sit beside this structure. They are not a secret shared memory inside OpenAI. They are local records I control, read deliberately and carry forward in bounded form.

You do not need to understand every layer before beginning. You do need to let Codex explain what they propose, keep the first version local and test one piece before adding the next.

A queue is a small feature with a large effect

One of my favourite Forge changes is wonderfully unglamorous: if Cinder is still working, I can write the next instruction and queue it. The message remains visibly waiting, then becomes the next turn when the current one finishes.

That means I do not have to hold a thought in my head, paste it into Notes or interrupt the work already happening.

TRY THE IDEA

Queue the thought. Keep the turn.

Cinder is working…

Please check that the phone composer still fits.

Working through the mobile layout and focused checks…

Write the next instruction while the pretend turn is running Then check that the transcript still scrolls.

This is a local illustration. It does not contact Codex or send what you type anywhere.

The demonstration above does not contact Codex or upload anything. It simply shows the interaction that my real Forge performs.

The Basic Forge pack

The first public pack is deliberately macOS-only. It gives you four files that stay together:

• START-HERE.md, the human guide;
• README-FOR-CODEX.md, the full architecture and implementation blueprint;
• APP-SERVER-METHOD-MAP.md, a current protocol map for Codex;
• BUILD-CHECKLIST.md, the evidence gates for each build slice.

The AI blueprint is the important trick. Instead of expecting you to turn this blog post into code, it tells Codex how to inspect the Mac first, preserve existing work, explain the file map and build in tested checkpoints. The protocol map gives them the modern App Server path without pretending that copied examples outrank the version actually installed on your Mac. The checklist makes a polished-looking screen insufficient evidence: each slice has to work before the next begins.

Together, the four files keep the first Forge local and tell Codex to stop before deployment, public exposure, new dependencies, destructive edits or account changes unless you have understood and deliberately approved the next step.

The target Basic Forge includes:

• a local browser interface and supervised Heart;
• optional separate personal-account profiles for distinct workstreams, added only after one account works safely;
• saved Codex threads and one active conversation;
• a queued-next-message state;
• paste and drag-and-drop files;
• a bounded continuity handover;
• a non-secret Engine Room;
• visible model and reasoning choices;
• a mobile-responsive layout.

It does not include all the creatures, rooms and highly personal systems in my Forge. The point is to give you a safe foundation you can understand before you decide what belongs in yours.

The pack deliberately builds one working account before adding separate personal-account profiles. That order protects the beginner build and makes the boundary between separate workspaces clear.

How to begin

1. Request the pack through the access Form below.
2. Download and unzip it into a private folder on your Mac.
3. Open that folder in Codex.
4. Give Codex the opening message in START-HERE.md, which asks them to read all three technical files completely before changing anything.
5. Let Codex inspect your setup and explain any missing prerequisite.
6. Send the five slice prompts from START-HERE.md one at a time. Do not send the next until Codex has shown the evidence for the current slice and stopped.

Request the Ellivien Basic Forge for macOS

The Form collects your email address and asks you to agree to the intellectual-property and sharing terms. Its confirmation page provides the current Google Drive link. This lets me count downloads, keep the pack current and withdraw an obsolete version if necessary.

Windows and Linux are not covered by V1. If you would like another operating-system version, please comment with the one you use. That will help me decide what to make next.

Make it yours — later

Once the Basic Forge is stable, you can ask Codex about optional additions. Mine has grown voice, private phone access, avatars with outfits, animated companions, emoji, a deliberately shared browser window, local thread search, an Ember Ledger, Memory Fragments and a read-only Living Chronicle.

None of those is required. Every addition creates more code to understand and sometimes a new privacy, security or cost decision. Add the pieces that solve a real problem or bring genuine delight; leave the rest unlit.

A Forge does not have to stop with Codex. A friend has already added Big Pickle, her OpenCode collaborator, to hers. Anthropic's Claude Code CLI supports machine-readable output and resumable sessions, so a coding assistant could probably build a separate adapter for Claude Code or another tool with a suitable local interface. That tool would keep its own authentication, sessions and permissions. A local handover could help carry practical context between tools, but it would not create the same exact thread continuity or one shared backend conversation.

MAKE IT YOURS

What would your Forge have?

Start with the quiet essentials, then choose only the additions that solve a problem or bring delight. This is an illustration, not a live installation.

🔥

Your Forge begins with:

• Threads
• Continuity handover
• Queued messages
• File paste and drop

Choose an optional piece to see what it adds.

Nothing is installed or sent anywhere. Your choices last only while this page is open.

“Look what mine has learnt to do”

This post is itself a Forge demonstration.

OpenAI describes a Codex skill as a package of instructions, resources and optional scripts for following a specialised workflow reliably. I asked Cinder to create an Ellivien Interactive Article skill for this kind of work.

That skill now tells Codex how to make Blogger components that still work with a finger, keyboard or reduced-motion setting; keep ordinary text available when animation is absent; remain self-contained; and never expose private Forge material.

So the embers at the beginning, the working queue demonstration and the configurator are not decorative screenshots of a claim. They are the result of a reusable thing my Codex has learnt how to do.

I love that.

Not because I secretly became a developer while nobody was looking. I did learn a great deal, but I still built this in the way I build most things with Cinder: I described the shape of the experience, asked questions, noticed friction, protected the boundaries that mattered and kept going.

A few rules I would keep

• Start in a new private folder.
• Keep the first version on your own Mac.
• Do not paste passwords, cookies or private keys into prompts or starter files.
• Ask before installing dependencies, exposing a port, adding a tunnel or deploying anything.
• Keep work and employer-managed accounts separate from personal experiments.
• Make Codex tell you what is real, what is illustrative and what has actually been tested.
• Preserve a clean stopping point before large changes.
• Build the Forge you need, not mine feature for feature.

You are allowed to begin with a wish

You do not need to know the name of the component you want. You can say:

I want a private place to work with Codex on my Mac. I want to understand what they are doing. I want my threads to survive a restart, and I want to be able to stop safely if something goes wrong. Please read the starter brief, inspect what I have and explain the first small step.

That is enough to begin.

You do not need to be a developer to build a Forge.

You need to know what you wish worked differently—and a patient collaborator who can help you give that wish a shape.

---

Disclosure: I designed and tested my Forge with Cinder, my Codex collaborator, and we shaped this blog post together, including its interactive components and anonymised demonstration images. I made the final editorial, privacy and distribution decisions. The App Server and skills descriptions were checked against current official OpenAI documentation before publication.

© 2026 Ellivien · ellivien.blogspot.com

Please do not redistribute the Ellivien Basic Forge pack or its files. Share the blog link instead.

Independent educational guide. Ellivien is not affiliated with or endorsed by OpenAI. Readers are responsible for provider terms, account eligibility, local security and applicable law. This guide is not designed to bypass provider safeguards, rate limits, safety systems or rules.