The branding check read `dev --help` only, which is why `dev exec`
announced "OpenAI Codex" as its banner for a while — `--help` never shows
it. It now reads every subcommand's help, and found four more leaks by
itself: exec's usage line, its --strict-config and --skip-git-repo-check
text, and `-c/--config` still naming ~/.codex/config.toml. That last one
was recorded as unreachable when a copied island could not include
utils/cli; editing the checkout in place made it reachable.
Two things keep the word legitimately and are exempt: CODEX_HOME, an
environment variable upstream owns, and `codex/...`, which names a method
on the app-server wire protocol. Renaming either breaks something real.
Branding is the product name a reader sees, not identifiers on a wire.
hanzo-upstream had no tests, and it is the code that edits upstream in
place — including an idempotence bug shipped earlier today that stacked
appending edits until `hanzo-tui` appeared three times in one manifest.
The anchor logic is now a pure function with six tests, one of which is
that exact regression, and one of which asserts every shipped anchor is
well formed. `make test` reaches the crate now; being a detached
workspace, the root run could not see it.
Cloud tasks are Hanzo Tasks, not the upstream service's name.
`codex-cli/` published `@hanzo/dev`, so the directory carrying our npm
package was named after someone else's product. It is `npm/`.
`patches/codex.json` is `patches/upstream.json` — it anchors edits against
upstream, and the file should say so rather than name one of them.
Deleted outright: `justfile`, whose first line was
`set working-directory := "codex-rs"` for a directory this repository has
never had; `announcement_tip.toml`, an example file for a TUI we do not
ship; and `.codex/` and `.code/`, which held upstream's own process skills
— babysit-pr, codex-bug, pushing-ci-changes — that were never ours.
Three branding leaks a real run turned up, none of which the help text
showed: `dev exec` announced "OpenAI Codex v0.7.0-dev.1" as its first
line, the status card was missed when the session header was anchored,
and both bubblewrap warnings said "Codex's Linux sandbox".
README: say what ships. It claimed the agent drives a browser, which is
the port that has not landed, and showed a screenshot of it doing so.
Both are gone until the bridge is back. The model count is "hundreds" —
`/v1/models` answers 458 today, an earlier line here said "over 500", and
hanzo.ai derives its own count precisely because typed ones drift.
Document the npm install beside the curl one; both give the same build.
LLM.md still described code-rs, build-fast.sh and a VT100 harness under a
directory this repo no longer has — and AGENTS.md, CLAUDE.md and GEMINI.md
all symlink to it, so it is the file every agent reads first. Rewrite it
for the workspace that is actually here, including the rule that upstream
is never edited by hand because `make bump` discards such edits.
Fix five broken images: the README pointed at docs/logo.png and
docs/screenshots/, and they live in docs/images/. Predates the cutover.
State the catalog honestly. "enso and the zen5 family" undersold a gateway
that answers for over five hundred models. Round, not exact — hanzo.ai
derives its count from the pricing snapshot and fails the build on a
hand-typed one, and a number typed here would drift the same way.
The docs read as OpenAI's Codex CLI: a getting-started page titled for it,
`codex --enable skills` and `code sandbox macos` for commands that do not
exist, defaults given as gpt-5.1-codex-max/openai when they are
zen5-coder/hanzo, a Homebrew page describing a formula we do not publish.
Removed three tui-stream-chunking notes and the execpolicy page: they
document modules and a subcommand that live only in the vendored upstream
copy. There is no execpolicy subcommand and no .codexpolicy loader in
code-rs; the page told users to run something the binary does not have.
Rewrote tui-alternate-screen against the source. It described an
auto/always/never enum and a --no-alt-screen flag; the shipped behavior is a
tui.alternate_screen bool with Ctrl+T, which replays the transcript into
scrollback on the way out — a better answer to Zellij than the one written
down. Genuine openai-provider documentation stays.
The README was upstream just-every/code text end to end: titled "CODE",
install lines `npx -y @just-every/code` and `npm install -g @just-every/code`
(a third party's package, which resolves and installs), clone URL
just-every/code.git, "Sign in with ChatGPT" as the primary auth, a block
telling readers to install @anthropic-ai/claude-code and @google/gemini-cli,
and an issues link pointing at just-every/code/issues — our support link
sending our users to someone else's tracker.
Replaced with our own copy. Install is `curl -fsSL https://hanzo.sh | sh`
then `hanzo auth login`; the command is `hanzo dev`. Every flag and slash
command listed was read off the shipped binary (hanzo 1.9.18) and the
SlashCommand enum, not copied. Model ids enso / enso-ultra / zen5-coder
verified against catalog.hanzo.ai. Fixed the THEME_CONFIG.md link, which
was a 404 at the repo root — the file lives in docs/.
Does not touch provider or model defaults or the release workflow.
Co-authored-by: Hanzo Dev <[email protected]>
- Disable rust-ci workflow temporarily due to clippy warnings from upstream merge
- Add comprehensive build caching to Release and rust-release workflows:
- Cache cargo registry and build artifacts
- Add sccache for compilation caching
- Optimize with parallel jobs and incremental compilation
- Fix Rust formatting issues
- Fix some critical clippy warnings (redundant closures, format strings)
- Performance improvements should reduce CI build times significantly
The builds were taking 15-20 minutes but should now be much faster with:
- Cargo registry caching
- Target directory caching with content-aware keys
- sccache for compilation caching
- Parallel job optimization
- Incremental compilation enabled
Major changes:
- Fixed slash command handlers receiving full command text instead of just arguments
- Added command_args extraction in app.rs to properly parse arguments
- Now /browser and /chrome commands receive only their arguments, not the full command
Browser improvements:
- Added Chrome browser integration with external Chrome DevTools
- Implemented virtual cursor visualization with smooth animation
- Added screenshot deduplication using perceptual hashing (pHash + dHash)
- Enhanced browser manager with Chrome connection support
- Added chrome_selection_view for browser mode selection UI
Image comparison:
- Implemented efficient image comparison using perceptual hashing
- Screenshots are now deduplicated to reduce token usage
- System shows "[Screenshot unchanged]" when identical screenshots detected
Code cleanup:
- Fixed unused variable warnings in browser/src/page.rs
- Marked unused image comparison function with underscore prefix
- All builds now compile without warnings
Co-authored-by: Hanzo Dev <[email protected]>
The function was expecting '/browser' to be in the command text and
looking at parts[1], but /chrome passes just 'chrome' or 'chrome [port]',
so we need to look at parts[0] instead.
- Changed index from parts[1] to parts[0] for first argument
- Fixed port parsing to use parts[1] instead of parts[2]
- Updated condition from parts.len() > 1 to \!parts.is_empty()
Co-authored-by: Hanzo Dev <[email protected]>
- Restore emoji characters in README.md for better visual appeal
- Remove Table of Contents markers requirement
- Disable ASCII-only and ToC validation for root README in CI
- Keep validation for codex-cli/README.md (maintains upstream compatibility)
This allows the fork to have a more modern, visually appealing README
while still maintaining compatibility where needed.
Co-authored-by: Hanzo Dev <[email protected]>
- Remove emoji characters from README.md to pass ASCII check
- Fix typo in chatwidget.rs: numer -> number for codespell check
Co-authored-by: Hanzo Dev <[email protected]>
Users on "headless" machines, such as WSL users, are understandable
having trouble authenticating successfully. To date, I have been
providing one-off user support on issues such as
https://github.com/openai/codex/issues/2000, but we need a more detailed
explanation that we can link to so that users can self-serve. This PR
aims to provide detailed information that we can link to in response to
user issues going forward.
That said, it would also be helpful if we employed heuristics to detect
this issue at runtime, and/or we should just link to these docs as part
of the `codex login` flow.
- Clean, focused documentation for the enhanced fork
- Clear installation instructions with npm package name
- Highlight key features and enhancements
- Add comprehensive usage examples
- Include troubleshooting and development sections
- Add comparison table with original Codex
- Remove outdated content and simplify structure
- Add clear branding as enhanced fork of OpenAI Codex
- Highlight new features (image support, /reasoning command)
- Provide npm installation instructions for @just-every/code
- Explain configuration directory behavior
This adds support for easily running Codex backed by a local Ollama
instance running our new open source models. See
https://github.com/openai/gpt-oss for details.
If you pass in `--oss` you'll be prompted to install/launch ollama, and
it will automatically download the 20b model and attempt to use it.
We'll likely want to expand this with some options later to make the
experience smoother for users who can't run the 20b or want to run the
120b.
Co-authored-by: Hanzo Dev <[email protected]>
On a high-level, we try to design `config.toml` so that you don't have
to "comment out a lot of stuff" when testing different options.
Previously, defining a sandbox policy was somewhat at odds with this
principle because you would define the policy as attributes of
`[sandbox]` like so:
```toml
[sandbox]
mode = "workspace-write"
writable_roots = [ "/tmp" ]
```
but if you wanted to temporarily change to a read-only sandbox, you
might feel compelled to modify your file to be:
```toml
[sandbox]
mode = "read-only"
# mode = "workspace-write"
# writable_roots = [ "/tmp" ]
```
Technically, commenting out `writable_roots` would not be strictly
necessary, as `mode = "read-only"` would ignore `writable_roots`, but
it's still a reasonable thing to do to keep things tidy.
Currently, the various values for `mode` do not support that many
attributes, so this is not that hard to maintain, but one could imagine
this becoming more complex in the future.
In this PR, we change Codex CLI so that it no longer recognizes
`[sandbox]`. Instead, it introduces a top-level option, `sandbox_mode`,
and `[sandbox_workspace_write]` is used to further configure the sandbox
when when `sandbox_mode = "workspace-write"` is used:
```toml
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
writable_roots = [ "/tmp" ]
```
This feels a bit more future-proof in that it is less tedious to
configure different sandboxes:
```toml
sandbox_mode = "workspace-write"
[sandbox_read_only]
# read-only options here...
[sandbox_workspace_write]
writable_roots = [ "/tmp" ]
[sandbox_danger_full_access]
# danger-full-access options here...
```
In this scheme, you never need to comment out the configuration for an
individual sandbox type: you only need to redefine `sandbox_mode`.
Relatedly, previous to this change, a user had to do `-c
sandbox.mode=read-only` to change the mode on the command line. With
this change, things are arguably a bit cleaner because the equivalent
option is `-c sandbox_mode=read-only` (and now `-c
sandbox_workspace_write=...` can be set separately).
Though more importantly, we introduce the `-s/--sandbox` option to the
CLI, which maps directly to `sandbox_mode` in `config.toml`, making
config override behavior easier to reason about. Moreover, as you can
see in the updates to the various Markdown files, it is much easier to
explain how to configure sandboxing when things like `--sandbox
read-only` can be used as an example.
Relatedly, this cleanup also made it straightforward to add support for
a `sandbox` option for Codex when used as an MCP server (see the changes
to `mcp-server/src/codex_tool_config.rs`).
Fixes https://github.com/openai/codex/issues/1248.
v0.2.0 of https://www.npmjs.com/package/@openai/codex now runs the Rust
CLI, so it makes sense to bring back the instructions to use `npm i -g
@openai/codex`.
In most places, I list `npm install` before `brew install` because I
believe `npm` is more readily available, though I in the more detailed
part of the documentation, I note that `brew install` will download
fewer bytes, and in that sense, is preferred.
As promised on https://github.com/openai/codex/discussions/1405, we are
making the first official release of the Rust CLI as v0.2.0. As part of
this move, we are making it available in Homebrew:
https://github.com/Homebrew/homebrew-core/pull/228615
Ultimately, we also plan to continue to make the CLI available in npm,
as well, though brew is a bit nicer in that `brew install` will download
only the binary for your platform whereas an npm module is expected to
contain the binaries for _all_ supported platforms, so it is a bit more
heavyweight.
A big part of this change is updating the root `README.md` to document
the behavior of the Rust CLI, which differs in a number of ways from the
TypeScript CLI. The existing `README.md` is moved to
`codex-cli/README.md` as part of this PR, as it is still applicable to
that folder.
As this is still early days for the Rust CLI, I encourage folks to
provide feedback on the command line flags and configuration options.
- Use Responses API for Azure provider endpoints
- Added a unit test to catch regression on the change from
`/chat/completions` to `/responses`
- Updated the default AOAI api version from `2025-03-01-preview` to
`2025-04-01-preview` to avoid user/400 errors due to missing summary
support in the March API version.
- Changes have been tested locally on AOAI endpoints
Right now since the repo is having two different implementations of
codex, flake was updated to work with both typescript implementation and
rust implementation
This PR introduces an optional build flag, `--native`, that will build a
version of the Codex npm module that:
- Includes both the Node.js and native Rust versions (for Mac and Linux)
- Will run the native version if `CODEX_RUST=1` is set
- Runs the TypeScript version otherwise
Note this PR also updates the workflow URL to
https://github.com/openai/codex/actions/runs/14872557396, as that is a
build from today that includes everything up through
https://github.com/openai/codex/pull/843.
Test Plan:
In `~/code/codex/codex-cli`, I ran:
```
pnpm stage-release --native
```
The end of the output was:
```
Staged version 0.1.2505121317 for release in /var/folders/wm/f209bc1n2bd_r0jncn9s6j_00000gp/T/tmp.xd2p5ETYGN
Test Node:
node /var/folders/wm/f209bc1n2bd_r0jncn9s6j_00000gp/T/tmp.xd2p5ETYGN/bin/codex.js --help
Test Rust:
CODEX_RUST=1 node /var/folders/wm/f209bc1n2bd_r0jncn9s6j_00000gp/T/tmp.xd2p5ETYGN/bin/codex.js --help
Next: cd "/var/folders/wm/f209bc1n2bd_r0jncn9s6j_00000gp/T/tmp.xd2p5ETYGN" && npm publish --tag native
```
I verified that running each of these commands ran the expected version
of Codex.
While here, I also added `bin` to the `files` list in `package.json`,
which should have been done as part of
https://github.com/openai/codex/pull/757, as that added new entries to
`bin` that were matched by `.gitignore` but should have been included in
a release.
- Added ArceeAI as a provider - https://conductor.arcee.ai/v1
- Compatible with ArceeAI SLMs (Virtuoso, Maestro)
- Works with ArceeAI's Conductor auto‑router models (auto, auto‑tool),
once #817 is merged
zeekay
