Coding agents care little about code readability. They often produce abstractions where you do not need them, and add layers of cruft where a simple function call would do. Why? Because they can read any code just fine, especially with additional help from code analysis tools. It could be JavaScript. It could be minified. AI don’t care.

So, how about closed-source Electron apps? Apparently, AI still don’t care, which is where it gets interesting. One frivolously successful prompt and a couple million expiring tokens later, that Electron app had the feature that I was missing!

However, patching a closed Electron app is one thing. Keeping the patch alive after the next release turns the quick weekend experiment into a chore. Every update can move the target. A JavaScript chunk gets renamed. A React component is compiled differently. An internal state path disappears. The app starts checking a different archive hash. A patch that worked yesterday now has to be rediscovered inside minified code that was never meant to be read by strangers. If a human has to do all of that by hand every time, the economics are terrible, for sure worse than the cost of changing tools and eco-systems.

Coding agents change the equation. They can search through ugly bundles of line noise without getting bored, compare versions, chase failing anchors, write tests, and run the same audit until the patch actually works. If it’s automated, in some select cases it might no longer obviously be more expensive than switching tools. The only required stimulus often is “Try harder.”

You might conclude that’s outrageous, and last week I probably would have agreed. But I was curious and Codex Plus is my test vehicle for this. It patches OpenAI’s Codex.app into a local Codex Plus.app. It does not ship Codex. It does not modify the source app. It checks the exact Codex version, bundle version, and original app.asar SHA-256 before it applies a patch queue.

There is nothing really new here, certainly not the patch strategy. People have modified closed and semi-closed clients for decades. However, with rapid release cycles (Codex sometimes releases several times per day!), the maintenance loop deserves attention. Codex Plus works as an ongoing experiment because the brittle pieces are mostly fenced in: exact version gates, small minified hooks, readable runtime plugins, and live audits against the running app.

This is not the “artificial intelligence reverse-engineered an app in five minutes” story. Those stories usually end before the next release breaks everything. Recent Codex Plus ports have taken roughly million-token-scale agent work. The work did not vanish, but it became bounded enough to repeat. It is largely automated besides some human-in-the-loop testing.

The upshot is that you can ask Codex (Plus) to modify itself now, if you are missing a feature!

What Gets Patched Link to heading

codex-plus-patcher works on an installed Electron application. Electron commonly stores application code in an Application Shell Archive (ASAR), named app.asar. Codex Plus reads the local Codex bundle, checks the app version, bundle version, and source archive hash, then selects the one patch queue that matches. If there is no exact match, it stops.

That fail-closed behavior is a safety rail. A patch written for one Codex build should not wander into another build because a similar string appeared in a minified file.

When a patch queue applies, the tool copies Codex.app to Codex Plus.app, rewrites selected packed ASAR files, adds readable runtime assets under webview/assets/codex-plus/, updates bundle metadata, refreshes Electron ASAR integrity metadata, and signs the copied app ad hoc. The source app stays where it was.

The important split is where the pain goes:

Layer What It Owns Why It Exists
Minified hooks Bundle-specific injection points Keep the fragile part small and exact
Host adapters Translation from Codex internals Hide private app details from plugin code
Runtime APIs Stable CodexPlus.* surfaces Give plugins a porting target
Plugins Commands, settings, styles, and feature behavior Keep user-visible behavior readable
Live audit Running-app checks through DevTools and probes Catch failures transform tests miss

The split decides whether the next port is survivable. Plugin code can call published CodexPlus.* APIs, but it should not know minified names, bundle filenames, React aliases, cache slots, or Codex-internal component names. Code that knows Codex internals belongs in a host adapter. A minified hook should install an extension point or call an adapter, not carry feature behavior.

Most of the work is not clever. It is counting anchors, checking hashes, proving a hook still fires, and refusing to call the job done because a text transform passed.

Client Mods Have Been Tried Before Link to heading

Codex Plus is new to me because of the app it targets. The pattern is old.

Vencord advertises more than 100 built-in plugins, browser extension and userscript support, custom CSS, and support across Discord release branches. Its FAQ also point out the legal ramifications: client modifications violate Discord’s terms of service, even if enforcement has not been the usual story. BetterDiscord offers themes, a plugin loader, a plugin application programming interface, and manual verification for official plugin updates. Spicetify customizes Spotify, and its documentation tells users that Spotify updates may require reapplying Spicetify. Replugged’s plugin guide expects TypeScript, React, and webpack knowledge.

Those projects differ from Codex Plus in size, audience, maturity, and risk. The overlap is that each turns private application structure into a local extension surface. The surface is not an upstream contract. It is a maintained agreement between the mod and the moving app underneath it.

Codex Plus has no large plugin community to spread out the labor. My bet is much smaller: let agents absorb enough of the search, comparison, and regression work that a one-person patch stays viable for a while. At least long enough to badger upstream into adopting enough of the new features that I can live with it.

Why Agents Help, and Where They Do Not Link to heading

Minified software is not entirely void of useful information. Names disappear, but control flow, string literals, imports, object shapes, event paths, and runtime behavior remain. That leftover structure is what an agent can work with.

Martin Alderson’s “Minification isn’t obfuscation” makes that case for JavaScript. His workflow uses agents with Abstract Syntax Tree (AST) analysis, where code is inspected as syntax nodes instead of raw text. The variable names may be useless, but an import edge, conditional branch, or return expression still gives the search something to grab. I tried it, but it seems to work about equally well without fancy tools, at least with current agents.

Security research is another interesting angle for this discussion. Cisco Talos described Large Language Model (LLM) assistance as a reverse-engineering sidekick, while still pointing to cost and context-window limits. The 2026 NDSS paper “Decompiling the Synergy” found that LLM help narrowed the novice/expert gap in software reverse engineering, but also produced hallucinations and ineffective suggestions. The survey paper “Potentials and Challenges of Large Language Models for Reverse Engineering” lands in the same place: lower barrier, real promise, persistent grounding problems.

Codex Plus runs into that boundary every time a new build lands. The agent needs the old patch, the new bundle, failing tests, exact error messages, and a way to inspect the live app. Without those anchors, it quickly derails.

The running app is the final judge. Codex Plus plugin debugging treats transform tests as necessary evidence, not sufficient evidence. A transform test can prove that code was inserted while saying nothing about whether Codex ever uses it. The patched app has to launch. The renderer at app://-/index.html has to be reachable through DevTools. Chrome DevTools Protocol (CDP) style inspection has to show the expected window.CodexPlus APIs, command metadata, plugin state, DOM attributes, and visible behavior.

That is where agents are most useful. They can keep the audit loop moving after the first plausible answer fails.

The Line Can Move Back Link to heading

The strongest objection to Codex Plus is operational. This is not a maintenance game I can win in the long term. Upstream controls the asset layout, minified names, React output, worker bridge, integrity assumptions, signing behavior, and user-interface structure. Exact version and hash gates prevent the wrong patch from applying, but they do not make the next patch cheap. A couple stable injection points (“plugin API”) would work. (NB: Codex has plugins, but not this kind.)

The economics can flip back quickly. If Codex changes too often, if the desired features become broader, if live audits take too long, or if a patch starts touching more sensitive surfaces, the answer should change. Stop patching. Switch tools. Wait for upstream. Drop the feature.

Codex Plus sits close to that line. That is what makes it worth studying a little longer.

Shift left, aka. Code wins arguments Link to heading

I do not really want Codex Plus to become a permanent shadow product. The better result is upstream pressure with receipts attached.

“Support nested repositories in the Review panel” sounds simple until the interface has to be designed. Should nested repositories appear before the main branch is selected? How should root and nested repositories be distinguished? What happens when a worktree contains several git boundaries? A working patch does not settle the whole design, but it turns the request into behavior people can inspect.

The same applies to a pop-out Mermaid diagram viewer, project identity colors, or a fuzzy project selector. A prototype gives upstream something concrete to accept, reject, copy, redesign, or ignore. In my book that is much better than the +1 on a Github feature request that might or might not ever get noticed.

Most closed-source patching is still the wrong answer. Codex Plus only makes sense because the apps runs locally to a large degree, the feature gaps are narrow, and the maintenance loop has live tests. Change any of those ingredients and the bargain gets worse.

For now, agent-assisted patching adds a third option between accepting a missing feature and moving to another tool. Build the local experiment. Keep the fragile part small. Measure the cost of each port. Stop when the numbers stop working.

Or, you know, in case anybody from the Codex team happens upon this: I’d fix it properly for a couple token grants and bragging rights!

References Link to heading