Forem: johnohhh1

Anthropic Limited Claude Subscription Usage for Third-Party Harnesses. So We Ported NanoClaw to Codex

johnohhh1 — Thu, 09 Apr 2026 19:01:29 +0000

NanoClaw started as an app effectively built by running Claude inside its own repo. Porting it to Codex meant rewriting not just the runtime, but the markdown instruction layer Claude had been using to build and operate the system.

Most "AI app ports" are not actually ports.

They are usually one of these:

swap the SDK
change the model name
keep the old runtime assumptions
call it done

This was not that.

On April 4, Anthropic began limiting Claude subscription usage for third-party harnesses, including tools in the OpenClaw/NanoClaw category, pushing that usage toward extra paid usage instead of normal subscription limits. That policy shift did not magically make NanoClaw unusable overnight, but it did make one thing obvious:

Building a serious agent system on top of a first-party subscription runtime is not a stable foundation.

NanoClaw started life as something much stranger and much more interesting: an agent harness that was not just running on Claude-native assumptions, but was also largely shaped by Claude while working inside the repo.

The original workflow was basically:

point Claude Code at the repo
give it a stack of markdown instructions
run commands like /setup
let it scaffold, extend, and evolve the app from inside its own preferred operating model

That means the old codebase was not merely "compatible with Claude."

It was, in a very real sense, built by running Claude inside a repo that was designed to teach Claude how to keep building it.

That distinction is the whole story.

Because once we decided to make NanoClaw truly Codex-native, the work was not "replace Anthropic with OpenAI."

The work was simple to describe and hard to do:

separate the app from the agent that originally co-authored its architecture.

The Weird Part: The Markdown Was Part of the Runtime

A lot of projects have docs.

NanoClaw had something closer to an instruction substrate.

The Claude-native version depended on a pile of markdown-driven behavior:

CLAUDE.md
.claude/skills/...
setup flows like /setup
branch/workflow docs
installer docs
capability docs
hidden conventions for how the agent should extend the app

These files were not just "developer notes."

They were part of the product's behavioral layer.

They told the agent:

how to initialize the app
how to install integrations
how to shape features
how to think about memory
how to extend channels
how to apply skills

So when we started the port, one thing became obvious fast:

some of the .md files were effectively code.

Not executable code in the TypeScript sense, but runtime-significant architecture in the agent sense.

That meant the port had two layers:

Port the actual Node.js/container runtime
Audit and rewrite the instruction layer that Claude had been using to build and operate the app

If we didn't do both, we wouldn't have a Codex-native system.

We would just have Claude-shaped behavior hiding under a new logo.

What NanoClaw Actually Is

At its core, NanoClaw is a small Node.js orchestrator for running isolated assistants in containers.

The host process handles:

channels
routing
SQLite state
scheduling
group registration
IPC
container lifecycle

The container handles:

the actual agent runtime
group-local context
active skills
delegated subagents
tool access via MCP

That architecture survived the port.

What changed was the substrate it was built on.

What Was Claude-Specific

Before the port, the Claude-specific assumptions were everywhere:

Claude SDK query loop
CLAUDE.md instruction contract
.claude/ state and session layout
.claude/skills/ install model
Claude slash-command workflows like /setup
Claude-era delegation semantics
remote control built around Claude tooling

And because Claude had been used to keep extending the app from inside the repo, those assumptions were reinforced both in code and in markdown.

So the first real task was not coding.

It was indexing and classifying the repo:

which parts were host application behavior
which parts were Claude-specific runtime behavior
which parts were portable concepts wearing Claude-shaped names
which markdown files were still product-significant
which markdown files were now just historical scaffolding

That review step mattered more than any individual code patch.

Because if you misclassify those layers, you end up deleting real features or preserving the wrong abstractions.

The Port Was Not "Remove Claude, Add Codex"

A real port required four kinds of changes.

1. Replace the runtime contract

The old container runner was built around Claude-native execution.

The new one is built around Codex CLI running non-interactively in the container.

That meant:

building prompt context from host state plus group instructions
invoking Codex cleanly for fresh turns and resumed turns
streaming results back through a stable host/container protocol
preserving session continuity where possible

This sounds like a simple runner swap.

It wasn't.

Because CLI contracts differ in annoying, subtle ways.

We hit real bugs around things like:

flags that work on codex but not codex exec
flags accepted on fresh turns but rejected on codex exec resume

Those are not theoretical portability problems. They are the kinds of issues that make a working-looking system fail in production after the host queue has already done its job.

2. Rewrite the instruction layer

This was the part that most clearly separated a fake port from a real one.

The Claude-native repo had accumulated behavior through markdown:

skills
setup flow
integration guidance
memory conventions
extension/install patterns

We had to go through those files and make hard calls:

convert
prune
delete
replace

That meant moving from Claude-specific conventions to Codex-native ones:

CLAUDE.md became AGENTS.md
repo/group skills became SKILL.md-based
old .claude/skills/ assumptions were removed
the setup story was rewritten around the current runtime rather than old slash-command flows

This was not glamorous work, but it was absolutely core to the port.

If the old markdown continues to teach the wrong mental model to the next agent working in the repo, the architecture drifts backwards immediately.

3. Keep the real product features

One of the easiest mistakes in a port is to treat every old feature as vendor-specific and quietly delete it.

That would have been wrong here.

Some things were truly Claude-specific and should die:

Claude SDK integration
Claude remote control
old Claude-only skill marketplace conventions

But other things were just app features that happened to be implemented in a Claude-native system:

Telegram
WhatsApp
web UI channel
subagent delegation
host skills

Those needed to be ported, not removed.

That was an important correction during this work.

The right question was not:

"Does this mention Claude?"

The right question was:

"Is this a real app capability, and does Codex have a legitimate equivalent or integration path?"

4. Make the host own the architecture

This is the core lesson of the whole effort.

The clean architecture is:

NanoClaw owns orchestration
NanoClaw owns state
NanoClaw owns channels
NanoClaw owns skills
NanoClaw owns setup
Codex is the agent backend

If the host owns those things, the backend is replaceable.

If the backend owns those things, the host is just branding.

The Bugs That Proved the Point

The best part of a port like this is that the bugs are revealing.

They tell you where your assumptions still belong to the old system.

Bug 1: The bot looked alive but was brain-dead

Telegram connected.
Messages were being stored.
But nothing was being processed.

Why?

Because WhatsApp was loading even when it was not configured, entering a reconnect loop, and blocking the async startup path before the message loop came online.

That produced a nasty half-working state:

inbound messages reached the DB
logs looked active
startMessageLoop() never really came alive
"NanoClaw running" never appeared

The fix was to stop treating channel startup as monolithic:

load channels conditionally from real config/auth state
allow channel connect failure without killing startup
skip missing channels cleanly instead of blocking the process

That sounds basic, but it was exactly the kind of bug you get when a system has grown around agent-era assumptions rather than explicit host orchestration.

Bug 2: The auth existed, but Codex still 401'd

This was my favorite bug in the whole port because it was pure systems work.

The host was logged into Codex.
The container was supposed to inherit auth.
But every in-container turn failed with:

401 Unauthorized: Missing bearer or basic authentication in header

The credentials were not absent.
They were misplaced.

The chain was:

auth was copied into a nested .codex/.codex/auth.json
that directory was mounted into the container
Codex expected auth relative to $HOME/.codex/auth.json
the file existed on disk, just not where the CLI actually looked

This is the kind of bug that disappears if you talk only in architecture diagrams.

It only becomes obvious when you trace:

host path
mounted path
container $HOME
actual CLI lookup convention

The fix:

flatten the per-group Codex state layout
mount it directly to /home/node/.codex
migrate old nested state forward

After that, the 401 vanished and the live message path finally completed.

Bug 3: Resume was not the same as fresh execution

Another seam bug.

We got fresh turns working, then resume failed because codex exec resume did not accept the same options as the fresh path.

That is a perfect example of why "we already integrated the CLI" is not enough.

You have to test:

fresh turn path
resumed turn path
session restoration
output handling after resume

Those are separate runtime contracts, even when they share most of the binary name.

What the System Looks Like Now

The current branch is not "Claude code with Codex paint."

It is a different runtime model.

Today it has:

Codex-native container runner
AGENTS.md for project/group instructions
SKILL.md-based host skills
per-group Codex state
Telegram, WhatsApp, and Web UI channels
Codex-backed delegation via MCP
host-owned setup and orchestration

And critically, it is no longer relying on the repo being interpreted through Claude-native markdown conventions to keep itself evolving correctly.

That was the actual finish line.

Not "build passes."

Not "logs look nice."

But:

the app can now be operated, extended, and reasoned about as a Codex-native system.

The Real Lesson

The strongest takeaway from this work is that agent-built systems can end up with architecture embedded in places most teams don't normally treat as architecture.

In this case, that meant:

markdown instruction files
slash-command setup flows
skill directories
implied agent workflows
hidden filesystem conventions

If you want to port a system like that, you have to audit all of it.

Not just the code.

Not just the API client.

All of it.

Because once an agent has spent enough time building inside a repo, the repo starts to encode assumptions about that agent's worldview.

That is fascinating when it works. It is dangerous when you need to switch runtimes.

If You're Thinking About Doing This Yourself

My advice is:

inventory the instruction layer before you touch the runtime
treat markdown conventions as potentially executable architecture
separate host ownership from backend ownership early
verify real CLI behavior instead of trusting docs from memory
test startup, auth, fresh turns, resumed turns, and recovery independently
do not call it a port if you quietly deleted capabilities that had real equivalents

The hard part is not replacing the model.

The hard part is identifying all the places where the old model had already shaped the app.

And once you do that, the job becomes much clearer:

you are not porting an SDK. You are reclaiming the architecture.

How I repackaged the official Windows Codex MSIX into a working Linux .deb

johnohhh1 — Thu, 09 Apr 2026 18:13:34 +0000

I wanted a real Linux desktop app for Codex.

At first, this looked like it should be straightforward: take the official Windows package, unpack it, swap in Linux Electron, rebuild whatever was platform-specific, and turn it into a .deb.

That is not what happened.

What actually worked was more pragmatic: preserve the official Codex payload, branding, and resources from the Windows MSIX, but replace the runtime shell with a small Linux Electron wrapper that opens Codex in its own desktop window.

This post is the write-up I wish I had before I started.

The Goal

The target was simple:

install Codex on Ubuntu as a .deb
get a desktop launcher and icon
make it feel like a native app
avoid relying on a browser tab
keep the build repeatable

I already had something similar working for ChatGPT, so I assumed Codex would follow the same path.

That assumption was wrong.

What I started with

The source payload was the official Windows MSIX:

OpenAI.Codex_26.313.5234.0_x64__2p2nqsd0c76g0.Msix

The repo I ended up with is here:

git@github.com:johnohhh1/codex-ubuntu.git

The main build script is:

./build-codex-native-deb.sh

The obvious approach

The first plan was the normal "repackage the Electron app" playbook:

Extract the MSIX.
Grab the bundled app.asar.
Swap the Windows Electron runtime for Linux Electron.
Rebuild or replace native modules.
Repackage everything into a .deb.

In theory, that should have produced a Linux .deb built directly from the original app bundle.

In practice, it failed in multiple different ways.

Problem 1: the Windows bundle was not actually Linux-ready

The Codex payload included resources and binaries that looked promising, but the packaged app still carried Windows assumptions.

The biggest issue was native modules.

At one point I confirmed the app was dying because a native dependency was still Windows-built:

invalid ELF header

That is the classic sign that Linux is trying to load a binary module compiled for the wrong platform.

So the next move was to rebuild native modules for Linux and wire them back into the extracted app.

That still did not get me to a usable app window.

Problem 2: getting the app to "launch" was not the same as getting it to work

I got as far as installing the package cleanly and starting Electron on Linux.

That was progress, but not enough.

The app process would launch and then exit without showing a window, or fail during startup after getting past the first set of issues.

This is one of the most annoying parts of Electron packaging work: "the binary started" sounds good, but it does not mean the app is actually viable.

Problem 3: Electron GPU startup was fatal on Linux

Once I simplified the runtime enough to observe the real failure clearly, the next blocker showed up:

FATAL: GPU process isn't usable. Goodbye.

That changed the direction of the fix immediately.

Instead of trying to preserve every part of the original desktop behavior, I needed a Linux-friendly launcher path that was stable in the actual Ubuntu session I was using.

The fix was to disable GPU at both levels:

in the Electron app itself with command-line switches
in the launcher wrapper used by the packaged .deb

The final launcher executes Electron like this:

exec /opt/codex-desktop-native/electron/Codex \
  --no-sandbox \
  --disable-setuid-sandbox \
  --disable-gpu \
  --disable-gpu-compositing "$@"

That was not elegant, but it was effective.

The pivot: stop trying to preserve the original runtime shell

This was the real turning point.

Instead of continuing to patch the original Windows desktop runtime deeper and deeper, I switched to a simpler architecture:

use Linux Electron as the runtime
keep the official Codex assets from the MSIX
build a tiny Linux wrapper app
load https://chatgpt.com/codex inside a dedicated desktop window

That approach still let me build from the official Windows MSIX, but it stopped me from getting trapped in the least portable parts of the original runtime.

What the final wrapper does

The generated wrapper app is very small.

It:

creates a BrowserWindow
hides the menu bar
uses a Codex title and icon
opens external popups in the default browser
allows normal http and https navigation
forces the window to show even if page paint is slow
points at https://chatgpt.com/codex by default

The wrapper also supports overriding the URL with an environment variable:

CODEX_WEB_URL=https://chatgpt.com/codex codex-desktop-native

That is useful if the endpoint ever changes or if you want a staging/test flow.

Packaging details that mattered

There were a few packaging details that turned out to be more important than I expected.

1. The app had to present itself as Codex

I renamed the Linux Electron binary from electron to Codex so the app identity looked correct on Linux.

That helped with launcher behavior and window class handling.

2. Desktop entry details mattered

The .desktop file sets:

Name=Codex
Exec=codex-desktop-native
Icon=codex-desktop-native
StartupWMClass=Codex
X-GNOME-WMClass=Codex

Without that, you can end up with weird launcher grouping or desktop integration issues.

3. Old install leftovers had to be cleaned up explicitly

Earlier experiments left behind app.asar.unpacked content from previous versions.

Even after the packaging approach changed, those leftovers could survive upgrades and create confusing behavior.

So I added a preinst cleanup step to the package:

rm -rf "/opt/codex-desktop-native/electron/resources/app.asar.unpacked"

That made upgrades deterministic again.

Making the build self-contained

At first I was borrowing tools from another workspace, which worked but was brittle.

I cleaned that up by making the project self-contained with local dev dependencies:

{
  "devDependencies": {
    "asar": "^3.2.0",
    "electron": "^40.0.0"
  }
}

That way the repo can be built with:

npm install
./rebuild-install.sh

instead of depending on some other directory on disk having the right binaries in it.

The build flow now

The working build pipeline looks like this:

Validate the MSIX input.
Extract the package and detect its version from AppxManifest.xml.
Copy the official assets into a staging directory.
Copy in Linux Electron.
Replace the original runtime shell with a generated Linux wrapper app.asar.
Build a .deb with the desktop entry, icon, launcher script, and package hooks.

The helper script for rebuild and reinstall is:

./rebuild-install.sh

The result

The final output is a package like this:

dist/codex-desktop-native_26.313.5234.0_amd64.deb

And the user-facing launch command is simply:

codex-desktop-native

Most importantly: it actually opens, stays up, and works as a desktop app on Ubuntu.

What I learned

The biggest lesson from this project is that "porting" is sometimes the wrong framing.

I went in thinking I needed to preserve the original Windows desktop runtime as faithfully as possible.

What I really needed was:

a reliable Linux package
a clean desktop launcher
Codex in its own app window
a build process I could rerun later

Once I optimized for that instead of purity, the solution got much simpler.

That tradeoff is worth stating directly: the final app is absolutely built from the official Windows MSIX, but it is not a perfect binary carryover of the original runtime. It is a Linux-native wrapper around the official Codex experience, using the original payload where it helps and replacing the parts that did not survive the platform jump well.

That was the right call.

If you want to try it

The repo is here:

git@github.com:johnohhh1/codex-ubuntu.git

Quick start:

git clone git@github.com:johnohhh1/codex-ubuntu.git
cd codex-ubuntu
npm install
./rebuild-install.sh
codex-desktop-native

Closing thought

A lot of cross-platform packaging work looks like a debugging problem, but the real work is architectural judgment.

You have to decide when to keep forcing the original design, and when to admit that a thinner, more native solution is the thing that will actually ship.

This project only started working once I made that call.

a build process I could rerun later

Once I optimized for that instead of purity, the solution got much simpler.

That was the right call.

If you want to try it

The repo is here:

git@github.com:johnohhh1/codex-ubuntu.git

Quick start:

git clone git@github.com:johnohhh1/codex-ubuntu.git
cd codex-ubuntu
npm install
./rebuild-install.sh
codex-desktop-native

Closing thought

A lot of cross-platform packaging work looks like a debugging problem, but the real work is architectural judgment.

You have to decide when to keep forcing the original design, and when to admit that a thinner, more native solution is the thing that will actually ship.

This project only started working once I made that call.

Run the Real ChatGPT Desktop App on Ubuntu Linux (Not a Wrapper)

johnohhh1 — Tue, 07 Apr 2026 13:51:17 +0000

TL;DR: OpenAI ships a Windows MSIX binary. You can unpack it, patch three platform assumptions, and run the actual official app natively on Ubuntu — same binary Windows users get. No Electron wrapper, no web view in a box.

The Problem With Every Other Guide

Search "ChatGPT desktop Ubuntu" and you'll find two things:

Articles pointing you at lencx/ChatGPT — a third-party Electron wrapper that loads chatgpt.com in a window. It's not the real app.
Articles pointing you at other wrappers doing the same thing.

These work, but you're getting a community-built shell around a website — not the app itself. The real ChatGPT Desktop (the one in the Windows Store) has features, update hooks, and auth flows that wrapper apps can't replicate cleanly.

This guide unpacks the official binary and runs it on Ubuntu 26.04. Tested on kernel 7.0.0, RTX 5070, NVIDIA 580/CUDA 13.0, both X11 and Wayland via XWayland.

What the Script Actually Does

Extracts the x64 MSIX from the official .msixbundle
Pulls out the official app.asar (the real app logic)
Patches three platform assumptions so it boots on Linux:
- Routes the platform chooser through the macOS-style implementation (Linux is close enough)
- Disables macOS-only setVibrancy() calls
- Skips the macOS ioreg device ID path
Stages Linux Electron around the official app resources
Packages everything as a proper .deb — chatgpt-desktop-native

You end up with a system package you can install, update, and uninstall like anything else.

Prerequisites

System packages

sudo apt-get install -y dpkg-dev nodejs python3 file

Local Electron tooling

mkdir ~/chatgpt-windows-deb && cd ~/chatgpt-windows-deb
npm install electron @electron/asar --no-save

Get the Official MSIX Bundle

You need the official Windows package from OpenAI. Download OpenAI.ChatGPT-Desktop_<version>.Msixbundle from the Microsoft Store or OpenAI's distribution endpoint and drop it in your working directory.

The repo includes the version current at time of writing as an example payload.

Build

cd ~/chatgpt-windows-deb
git clone https://github.com/johnohhh1/chatgpt_desktop_ubuntu .
npm install electron @electron/asar --no-save
./build-chatgpt-native-deb.sh --exe ./OpenAI.ChatGPT-Desktop_2026.212.2039.0.Msixbundle

Output lands in dist/:

dist/chatgpt-desktop-native_2026.212.2039.0_amd64.deb

Install

sudo apt-get install ./dist/chatgpt-desktop-native_2026.212.2039.0_amd64.deb

Rebuilding without a version bump? Force refresh:

sudo apt-get install --reinstall ./dist/chatgpt-desktop-native_2026.212.2039.0_amd64.deb

Register Auth Callback Handlers

The package installs a helper that registers your desktop session as the handler for the chatgpt: and chatgpt-alt: URL schemes (used for the login flow):

chatgpt-desktop-native-register

Verify it took:

xdg-mime query default x-scheme-handler/chatgpt
xdg-mime query default x-scheme-handler/chatgpt-alt

Both should return chatgpt-desktop-native.desktop.

Launch

chatgpt-desktop-native

The desktop entry sets the WM class to electron so GNOME binds the running window to the ChatGPT icon instead of the generic gear icon.

Known Quirks

The terminal will print Electron/NVIDIA/VA-API noise. This is normal — ignore it.
The success signal is functional login and working chat, not a clean terminal.
If GNOME still shows the generic icon after first launch: close the app fully and relaunch once. Stubborn shell? Log out and back in.
If OpenAI updates the Windows app significantly, the patch targets in build-chatgpt-native-deb.sh may need updating. PR welcome.

Reproducing on Another Machine

Clone the repo to the target machine
Drop a real ChatGPT .msix, .msixbundle, .appx, or .appxbundle in the directory
npm install electron @electron/asar --no-save
./build-chatgpt-native-deb.sh --exe <your-payload>
Install the generated .deb
Run chatgpt-desktop-native-register
Launch chatgpt-desktop-native

Repo

github.com/johnohhh1/chatgpt_desktop_ubuntu

Issues and PRs open. If a new MSIX version breaks the patches, open an issue with the version string and I'll update the patch targets.

Tested on Ubuntu 26.04 "Noble" with kernel 7.0.0-10, RTX 5070, NVIDIA driver 580, CUDA 13.0.