Installation

Installation

The release installer is the normal path. It installs the native binary, registers the per-user background service, and keeps the installation in the standard location that self_update can manage. Manual archive and source installs remain available.

Prerequisites

• An OpenAI/ChatGPT account with Developer mode for the connector (a ChatGPT Plus/Pro subscription is what makes the connector usable).
• Git on your PATH if you want the git tools and diff checkpoints to work (recommended).
• For the native OpenAI tunnel (recommended connection mode), you'll create a tunnel ID and a restricted runtime API key later — see Connecting to ChatGPT.
• To build from source only: a recent Rust toolchain (edition 2024).

Option A — Release installer (recommended)

Linux and macOS:

curl -qfsSL https://codexify.dev/install.sh | sh

Windows PowerShell:

powershell -ExecutionPolicy ByPass -c "irm https://codexify.dev/install.ps1 | iex"

The installer downloads the latest GitHub release, verifies it against the published SHA-256 checksums, and installs the executable under ~/.codexify/bin. On Unix it adds that directory to recognized shell profiles; on Windows it updates the persistent user PATH. The macOS installer also removes the executable's quarantine attribute.

By default the installer also registers and starts Codexify as a per-user background service. Set CODEXIFY_SKIP_SERVICE=1 in the installer process if you deliberately want only the executable and PATH entry. After installation, restart the terminal so the new PATH is visible, then run:

codexify quickstart

Migrating an existing Codex Free installation

When legacy ~/.codex-free state exists, the installer migrates it into ~/.codexify. The old configuration is rebased onto Codexify's defaults so settings are carried forward only when they differed from the old Codex Free defaults; existing Codexify values win conflicts. The migration also rewrites renamed state paths and review configuration to diff, while keeping pre-rename conversation, authorization, diff-checkpoint, and worktree state addressable across the renamed namespaces. Conflicting legacy state files are retained rather than silently overwriting newer Codexify state.

Option B — Manual release archive

Each release ships one native binary per platform:

Platform	Archive
Windows x64	windows-x64
Linux x64	linux-x64
Linux arm64	linux-arm64
macOS Intel	darwin-x64
macOS Apple Silicon	darwin-arm64

1. Download the archive for your OS/arch from the Releases page.
2. Verify the checksum against the published SHA256SUMS (each release publishes checksums alongside the archives).
3. Unpack it.
4. Put codexify (or codexify.exe) somewhere on your PATH.

These are native builds, so there is no AVX2/baseline caveat — the binary runs on any CPU of its architecture.

Verify it runs:

codexify --help

Option C — Build from source

git clone https://github.com/devnoname120/codexify.git
cd codexify
cargo build --release
# binary is at target/release/codexify

You can also run without installing:

cargo run --release -- --work-dir /path/to/your/project

Everywhere this wiki writes codexify …, the source-checkout equivalent is cargo run --release -- ….

Background service

The release installers register a native per-user service and enable it for future logins:

Platform	Service
Linux	systemd user unit codexify.service
macOS	launchd agent ~/Library/LaunchAgents/dev.codexify.service.plist
Windows	Task Scheduler task Codexify

The service runs the normal server through the hidden supervisor command codexify service run --config /absolute/path/to/codexify.config.json. It waits if the config has not been created yet, restarts a failed server with bounded backoff, and writes rotating logs under ~/.codexify/logs/.

Useful service commands:

codexify service install
codexify service enable
codexify service disable
codexify service logs
codexify service logs -f
codexify service remove

service install uses ~/.codexify/codexify.config.json unless --config selects another absolute config path. quickstart writes an absolute workDir and restarts an already-installed service automatically. For service-managed configurations, prefer file:/absolute/path secret references because login services do not necessarily inherit variables exported only by an interactive shell.

Updating Codexify

For a standard ~/.codexify/bin installation, ChatGPT can call the self_update MCP tool after you explicitly request an update. The tool requires confirm=true, downloads the latest GitHub release, verifies its checksum, probes the staged binary, and schedules a detached updater.

When Codexify is service-supervised, the updater waits for the tool response to be delivered, stops the service, atomically swaps the executable while retaining a rollback copy, validates the replacement, and restarts the service. The MCP connection therefore disconnects temporarily. Follow progress with:

codexify service logs -f

With uiWidgets: true, self_update uses the built-in MCP App resource ui://codexify/self-update/v1/mcp-app.html; its private self_update_status helper reads the durable phase record after reconnect/restart. With widgets disabled, the update authority is unchanged and the service log is the progress surface.

After Codexify restarts, refresh the connector schema in ChatGPT: open Settings, select the Codexify connector, scroll to the bottom of its tool list, and click Refresh. This makes ChatGPT reload the tools exposed by the updated server. The old conversation may still retain its previous model-visible schema; when the setup app reports that the connector is current but the conversation is stale, use its handoff/continuation flow to start a new conversation on the same workspace.

Self-update refuses source-tree and nonstandard executable locations. On Windows it additionally requires Codexify to be running under the background service because the running executable cannot be replaced in place. A foreground Unix installation can replace the on-disk binary, but the already-running process continues using the old version until restarted.

Where Codexify keeps its data

Codexify never writes into the project you point it at. Its own state lives under your home directory in ~/.codexify/:

Path	Holds
~/.codexify/openai-tunnel/	The managed OpenAI tunnel client runtime and its pinned install manifest
~/.codexify/openai-tunnel/credentials/	Per-tunnel runtime key files written by quickstart (Unix: mode 0700/0600)
~/.codexify/projects/<name>-<hash>/memory.json	Per-project plan and notes (see Context and Memory)
~/.codexify/conversation-projects/	Per-conversation project bindings in multi-project mode
~/.codexify/connector-schemas/	Endpoint- and caller-hashed records containing only the last Codexify version served through tools/list, used by the setup app to distinguish connector refresh from a stale conversation
~/.codexify/artifacts/	Durable native exported-file capability records, private immutable snapshots, and store locks; snapshot bytes are bounded by artifactEgress.maxSnapshotBytes
~/.codexify/update/status/	Durable detached self-update phase records read by the updater app across service restart
~/.codexify/logs/codexify.log	Rotating background-service and self-update log

It also reads (never rewrites) Codex's own config at $CODEX_HOME/config.toml (default ~/.codex/config.toml) to discover MCP servers and, in multi-project mode, project candidates.

Next step

Head to Quick Start for the guided setup, or CLI Reference if you'd rather wire everything by hand.