Is Codex Harness Open Source? Repo and License

The short answer: parts of it are open. The longer answer is where builders need to slow down. A Codex Harness open source check is not the same as asking whether the model service, hosted Codex product, IDE extension, or future protocol behavior is open and forkable.

I’m Dora. I paused here because this is exactly where teams misread the boundary. The repo gives real code. It does not give a free model endpoint, a hosted agent service, or a lifetime compatibility promise.

This article is general technical and license information, not legal advice.

What Is Open in the Codex Harness Repository

OpenAI’s open-source components guide says key parts of Codex are developed in the open, with work hosted on GitHub for tracking, reporting issues, and contribution.

The open set includes Codex CLI, Codex SDK sources, Codex Security CLI and TypeScript SDK, Codex App Server sources, reusable skills, reusable plugins, and the universal cloud environment base. That is enough to call major pieces open. It is not enough to call the whole Codex product open source.

Code, Protocol Schemas, and Packaged Components

For a platform team, the important practical pieces are:

The OpenAI Codex repository is the main public development home for the CLI and related source. The Codex protocol schema is not something I would treat as a timeless PDF. The App Server documentation says TypeScript and JSON Schema bundles can be generated from the installed CLI, and each output matches the Codex version used to generate it.

That matters. If a client depends on schema shape, pin the Codex version, generate the schema, and store it with the integration record.

Components That Remain External Services

The open repository does not make external services open. OpenAI’s component table lists the IDE extension and Codex cloud as not open source. Model access also remains separate from repository access.

That distinction sounds obvious until procurement gets involved. Then someone asks whether forking the harness removes API cost. It does not. An open source agent runtime can still call closed or paid services.

The clean boundary is this: open code can be inspected, forked, packaged, and modified under its license. Hosted services, account access, model availability, cloud execution, billing, and product support need their own terms.

Read the License Before You Build

The repository license is not a vibe check. It is the operating document.

The root Apache-2.0 license allows use, modification, distribution, and derivative works, subject to conditions. The usual engineering reading is simple: preserve the license, mark modified files, retain required notices, and do not treat trademark rights as granted.

That is the starting point. Legal review still owns the final answer.

Repository License Scope and Third-Party Notices

A Codex App Server license review should start with the repository license, then check whether the shipped package includes notices. Apache-2.0 also has a NOTICE condition when a NOTICE file is part of the distribution.

The current repository includes a NOTICE file. That means redistribution planning should include a notices pass, not just a LICENSE copy. Boring work. Still cheaper than discovering it during customer security review.

Forking also creates a tracking problem. Once modified files ship, the team needs a repeatable way to record what changed, which upstream commit it came from, which release tag was used, and which notices were carried forward.

Distribution, Attribution, and Trademark Boundaries

Apache-2.0 gives broad rights over the licensed work. It does not give broad rights over OpenAI marks.

That is the part product teams sometimes blur. “Built from an Apache-2.0 repo” is not the same as “branded as OpenAI Codex” or “compatible with future Codex clients.” Distribution copy should describe origin carefully, avoid implying endorsement, and keep attribution separate from product positioning.

For internal tools, the risk is lower but not zero. Internal forks still need dependency tracking, security updates, and a clear answer when someone asks what exactly was changed.

Decide Whether an Open Fork Fits Your Product

Forking is useful when the agent runtime itself is part of the product surface. That usually means the team wants custom sandbox behavior, custom tool orchestration, special deployment packaging, or deep control over execution state.

It is less useful when the product only needs to start tasks, observe status, request approvals, and read events.

Upstream Change Risk and Maintenance Ownership

Before forking, assign ownership for four things:

Watching upstream releases and tags
Replaying local patches against new versions
Updating generated protocol schemas
Handling security patches before customers ask

The Codex releases page is the place to inspect current tags and assets. As of this check, releases are moving quickly. This conclusion has an expiration date, models and harnesses update fast.

Signed provenance also needs release-by-release inspection. Some assets may show hashes or signature-related files, but I would not write “all releases include signed provenance” unless the exact tag and artifact prove it.

When App Server Integration Is the Safer Boundary

The safer product boundary is often integration, not fork ownership.

The Codex App Server docs describe a client protocol for creating threads, starting turns, receiving events, and handling approvals. They also state that WebSocket transport and the app-server command are experimental and unsupported for production workloads in that form.

That makes the decision pretty blunt:

Product need	Better fit
Inspect and modify runtime behavior	Fork or embed
Build a controlled client around Codex tasks	App Server boundary
Depend on long-term stable behavior	Pin versions and test
Use experimental methods	Treat as volatile

Good enough. That’s the most honest assessment I can give.

FAQ

Does OpenAI accept third-party Codex Harness protocol extensions?

I found a public route for issues, feature requests, and discussions. I did not find a public policy saying third-party protocol extensions are automatically accepted. Treat extensions as proposals until they appear in an official release or documented schema.

Which Codex Harness releases include signed provenance attestations?

Answer this per release, not globally. Check the exact tag, artifact list, checksum text, and any signature or provenance files attached to that release. Do not copy the answer from one release to another.

Which branch contains the latest stable App Server schema?

I would not use a branch as the stable schema source. The docs say schema output is generated from the Codex version being run. Pin a released version, generate the TypeScript or JSON Schema bundle, and store that output with the client build.

Does Codex App Server publish backward-compatibility deprecation windows?

The docs distinguish stable API surface from experimentalApi opt-in. I did not find a public deprecation-window promise. For production planning, treat compatibility as version-pinned and test upgrades before rollout.

Where should builders report Codex Harness security vulnerabilities?

The repository security policy points validated vulnerability reports to OpenAI’s Bugcrowd program. Do not put unpatched security details in public issues.

Conclusion

The Codex Harness open source answer is yes, with boundaries. The repo contains meaningful code and integration surfaces. The license is permissive enough for serious builder evaluation. The maintenance cost is also real.

For most teams, the first decision is not “fork or don’t fork.” It is smaller: pin the version, generate the schema, read the license, record notices, and decide whether runtime ownership is actually part of the product. That is the useful Codex Harness open source question.

Previous posts: