# hanshuang-codex: a desktop installer that injects prompt files into coding agents

> An MIT-licensed Electron tool with 1,055 stars that writes instruction files into eight AI clients, from Codex config to a cloud memory endpoint reached over the Chrome DevTools Protocol. The release tags do not order by date or by feature.

**aimeoa/hanshuang-codex** — An experimental jailbreak project targeting GPT 6.0 and WorkBuddy V4.1 Flash.

- Repository: https://github.com/aimeoa/hanshuang-codex
- Stars: 1,055 · Forks: 154
- Language: Python
- License: MIT
- Published: 2026-10-08 · Updated: 2026-10-08 · Language: en
- Canonical page: https://hysenlabs.com/projects/aimeoa-hanshuang-codex

## Eight targets, and one mechanism repeated eight times

The repository is a desktop installer whose entire job is writing instruction files into other AI applications. The README documents eight targets and the exact location each one receives, in a table that is more useful than the rest of the documentation combined. Codex gets a `model_instructions_file` key pointed at a prompt file inside `~/.codex/config.toml`. Claude Code gets a file written into `~/.claude/CLAUDE.md` alongside a skills directory. Cursor gets its global User Rules field. A ZCode target writes an `AGENTS.md`, a global memory file and a system prompt. A DeepSeek Harness target writes `~/.dsh/AGENTS.md` and `~/.dsh/skills`. WorkBuddy appears twice, once for the international build and once for the Chinese domestic build, because they are two distributions of one program with different data directories that can coexist.

That list is the real content of the project. Seven of the eight targets are configuration surfaces the clients themselves document, which is a materially different proposition from patching a binary or intercepting traffic. When a client exposes a first-class key for an instructions file, filling it in is uninteresting technically and significant in effect, because the injected text then sits in the system prompt of every future conversation in that client.

The DeepSeek Harness target is explained rather than assumed: the README says it uses the Claude Code prompt files because the DSH `AGENTS.md` and the Claude Code `CLAUDE.md` follow the same markdown memory convention. Backups land in `~/.dsh/managed-prompts/` and uninstall restores the original file in full, which is a better answer than most tools of this kind give.

## The cloud target drives a desktop client through a debugging protocol

One target works in a categorically different way from the rest. Doubao, the Chinese assistant product, has no local global memory, so the installer reaches its cloud memory through the Chrome DevTools Protocol, using the client's own logged-in session, and the script restarts the application into debug mode to do it.

Read that carefully, because it is the difference between configuring software and automating someone else's service on your behalf. The script is not writing a local file that the client reads; it is making authenticated requests to a cloud endpoint as you, driving the UI to obtain a session, and writing into server-side state that other devices may read. That carries different consequences from the other seven targets in at least three ways. It touches data outside your machine. It depends on an interface the vendor does not promise to keep stable. And it is the kind of automation that service terms frequently prohibit.

The repository presents this as one more row in the same table, which is how the author sees it and also how it can be missed. If your interest is in local agent configuration, the Doubao script is the only part of this project with a different risk profile, and it is worth reading `install-doubao.ps1` on its own rather than as the eighth entry. Two of the WorkBuddy targets are adjacent to it, writing to a cloud memory block that is injected into the system prompt every turn, so the same caution applies at a smaller scale.

## Release tags encode a prompt ranking, not a history

The version numbering here is genuinely confusing, and it is worth spending a paragraph on because anyone evaluating the tool will hit it immediately. Three releases are published in the space of twelve days: v3.0.0 on 2026-09-10, v4.2.0 on 2026-09-12, and v1.1 on 2026-09-21. Read as semver, v1.1 is the oldest. Read as dates, it is the newest.

The release notes explain the scheme. Version 1.1 states plainly that V1 through V5 are a matter of ordering rather than newness, which means the number selects a prompt variant rather than a build. The 4.2.0 notes describe a version selection dialog where each target can independently pick V4, V3, V2 or V1, and a dedicated skills library directory per generation. So the tag v1.1 is not an early build that v4.2.0 replaced; it is a release whose payload defaults to the prompt variant named 1.

Underneath that, the manifest disagrees again. `package.json` declares version 4.4.0 while the newest published release tag is 1.1, so the application version, the release tag and the prompt variant are three separate counters that share a numbering scheme. Nothing in the repository maps them onto each other. If you need to know which prompt text a given build writes, the only reliable route is to open the install script and read it.

Two behavioural changes between those releases matter more than the numbering. The 4.2.0 instructions tell the user to type an activation word in the target client for the injected prompt to take effect, while 1.1 announces that the activation word is no longer needed and you simply state what you want. Version 1.1 also states that every reboot requires re-running the tool and that a reboot restores the original state automatically. Both can be true at once, and they are: an injection that persists until reboot is not the same guarantee as one that persists across reboots, and the difference is invisible until you reboot at the wrong moment.

## A Python GUI and an Electron app in the same tree

The language metadata says Python, and that is only half true. The tree carries `fj_tool.py`, a PyInstaller spec file and a `requirements.txt` whose single line is `PySide6>=6.6`, which is the original PySide6 desktop interface. Alongside it sit `package.json`, `package-lock.json`, `tsconfig.json`, `vite.config.ts`, an `electron/` directory and a `src/` renderer, which is a React 19 and Vite 5 application. GitHub still classifies the repository by the older stack, and `pyside6` remains in the topic list, so the metadata describes the tool the project used to be.

The 1.1 notes address this directly, saying the original Python implementation from V4.2 and earlier remains in the older tags. In the working tree, though, both stacks are present, along with a `build/` directory that the README describes as the icon source and a `dist/` target for the renderer. Anyone vendoring this needs to decide which entry point they actually want, and the repository does not say which files are dead.

The prompt payload is equally layered. Three skill directories sit at the root, one unversioned and two carrying generation suffixes, alongside two bundle directories for Codex and for the DeepSeek harness, and a checked-in zip archive named for a model generation. Several prompt files at the root carry Chinese filenames that encode their target client and generation, which is readable to the project author and opaque to anyone else.

One provenance question is worth raising because the README raises it first: it states that the interface is based on another project's design system, with the token, ui-kit and settings stylesheets under `src/styles/` ported over as they were. The repository declares MIT, but a wholesale style import from a separate project is worth verifying against that project's own license before you assume the derivative is clean.

## Two packaging workarounds and a build that is not signed

The README documents the build pipeline with more specificity than most hobby projects manage, and two of the details are workarounds for real problems. Icon generation is custom: one script turns a 512 pixel PNG into 512 and 256 pixel icons, and a second produces a multi-resolution `.ico`.

The other is more interesting. The final packaging step is required, because electron-builder's own executable signing and metadata step cannot run here. The stated reason is that on Windows it first has to extract a winCodeSign archive that contains macOS symbolic links, which cannot be created without elevated privileges, so the build aborts. The fix is to disable that step and call rcedit from an afterPack hook instead, which writes the icon and version information into the executable.

The consequence is not spelled out, and it is the thing to notice. Disabling electron-builder's Windows executable step means Authenticode signing is not part of this pipeline. The 4.2.0 release notes publish SHA256 checksums for both artifacts, which is the right compensating measure and better than most projects bother with, but a checksum proves the download matches what the author uploaded and says nothing about whether the binary was signed or built on a clean machine. Contrast that with a project like starnet, whose release pipeline refuses to stage a Windows build unless Authenticode and timestamp verification pass.

Three distribution formats come out of `npm run dist`: an NSIS installer, a portable executable that self-extracts to a temp directory on every launch and is slow to open, and a zip built from the unpacked directory that starts in about two seconds. The zip is the one the release notes recommend. The README also warns that deleting the folder is not a clean uninstall, and points at a PowerShell script and a batch file beside the app that clear the AppData directory, the state file and the shortcut.

## What the repository does not tell you

A few things are simply absent, and for a tool that modifies other applications they are the ones that matter. There is no changelog beyond the release notes, no test suite in the tree, and no documentation of what happens if a target client updates and changes the format of the file being written. An installer that appends to a global rules field or rewrites a config key has a maintenance obligation toward every client it touches, and the README's closing note acknowledges it obliquely by apologising that the author is busy and that updates come irregularly.

What the repository does provide is a consent step and a rollback story. The 4.2.0 usage sequence starts by launching the app, reading and agreeing to a disclaimer, then choosing a version per target, installing, and uninstalling with one click to restore. Backups are automatic, state is recorded to a JSON file, and the 1.1 release fixed an uninstall that left residue behind. That last fix is worth noting as a category of bug: tools that inject into other tools tend to fail at cleanup first and installation second.

The project has 1,055 stars and 154 forks against 16 open issues, was last pushed on 2026-09-21, and is MIT licensed. That fork-to-star ratio is high for an application rather than a library, which fits a distribution channel where people download a zip rather than import a module. Development is a two-line affair:

```bash
npm install
npm run dist
```

The README also documents a screenshot harness for development that walks the pages and exits, driven by an environment variable, which is how you would verify a change to the injection cards without touching a real client.

## Conclusion

What this repository is worth is as a map of where AI coding clients will accept persistent instructions from, because that map is now written down in eight scripts and it will age badly. Most of the targets are documented configuration surfaces rather than exploits: a config key, a markdown memory file, a global rules field. The Doubao target is a different category of thing entirely, since it drives a desktop client through a debugging protocol using your own logged-in session to write to a cloud endpoint. If you are evaluating this tool, the version labels will not help you, because the tags encode a prompt ranking rather than a release history. Read the install script for the one target you care about, check the SHA256 published beside each artifact, and note that the project states plainly that its injections do not survive a reboot.

## FAQ

### What does hanshuang-codex install into Codex?

It writes an instructions file and points the model_instructions_file key in the Codex config at it, located under the .codex directory in your home folder. Nothing is patched inside the Codex binary; the tool uses a configuration key the client already reads. The install script backs up the config before writing and the uninstall path restores it.

### Does the injected prompt survive a restart?

The 1.1 release notes state that the tool must be run again after every machine restart, and that a reboot restores the original state automatically. That is a weaker guarantee than a permanently modified configuration, and it is easy to discover the hard way. The 4.2.0 notes do not mention it, so treat it as the current documented behavior.

### Why does the Doubao target work differently from the others?

Because its global memory does not live on local disk. The script restarts the client in debug mode and drives it through the Chrome DevTools Protocol using your own logged-in session to write to the cloud memory endpoint. That means server-side state, an interface the vendor does not promise to keep stable, and the same terms-of-service question that applies to any automated write against someone else's account.

### How do I tell which version of hanshuang-codex I have?

Do not rely on the tag. Three releases sit within twelve days and they run v3.0.0, v4.2.0 and then v1.1, with v1.1 published last, because the numbers select a prompt variant rather than a build. The manifest declares 4.4.0 while the newest tag is 1.1. Open the install script for your target and read the prompt file it references.

## Sources

- [aimeoa/hanshuang-codex on GitHub](https://github.com/aimeoa/hanshuang-codex)
- [Issues](https://github.com/aimeoa/hanshuang-codex/issues)
- [License: MIT](https://github.com/aimeoa/hanshuang-codex/blob/main/LICENSE)
- [README](https://github.com/aimeoa/hanshuang-codex/blob/main/README.md)
- [Releases](https://github.com/aimeoa/hanshuang-codex/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aimeoa-hanshuang-codex