How to Install Fugu in Codex: Full Setup, Flags & Backups

The Codex integration is the most complete way to run Sakana Fugu in a coding agent: a launcher that keeps your config current, a version-pinned Codex known to work with Fugu’s configs, and a real backup system for everything it touches. This guide covers the one-line install, every launcher flag, the full manual setup, and how version pinning and backups behave. All of it verified against Sakana’s official repository and get-started page on August 19, 2026.

The one-line install

curl -fsSL https://sakana.ai/fugu/install | bash

The bootstrap clones the repo to ~/.fugu, then asks whether to set up Codex, Claude Code, or both (Codex-only: append -s -- --codex; it’s also the headless default). The Codex installer then pins the Codex CLI, deploys the Fugu config, and stores your fish_ API key. Non-interactive, for CI or provisioning:

curl -fsSL https://sakana.ai/fugu/install | SAKANA_API_KEY=your_key FUGU_INSTALL_TARGET=codex bash -s -- --yes

Supported platforms: Ubuntu and macOS (Windows: see the Windows guide). Afterwards, launch with:

codex-fugu

which runs codex -p fugu — Codex with the Fugu profile — plus an hourly config-update check that never blocks launch.

Version pinning: why your Codex version may change

Fugu’s configs are verified against a specific Codex version — 0.147.0 as of August 19, 2026, per the repo’s release notes. On a mismatch, the installer offers to switch your Codex binary to the pinned version, and the launcher offers the same reconcile at most once an hour. A switch only ever happens with your consent (an interactive yes, or --force).

One side effect to know: Codex keeps a per-version session index, so after a version switch, codex resume lists different past sessions. Your transcripts under ~/.codex/sessions are never deleted — only which sessions the resume list shows changes. To get an earlier resume list back, run the Codex version that wrote it, or restore the saved session index from a backup:

cp -p ~/.codex-backups/codex-config-<timestamp>/*.sqlite* ~/.codex/

To pin a different Codex version, use --pinned-version X.Y.Z on the installer (or the FUGU_PINNED_VERSION / CODEX_RELEASE environment variables).

Launcher flags

FlagWhat it does
--statusShow installed version, pinned target, and update state
--set-keyRotate the stored Sakana API key
--checkCheck for a config update now, instead of waiting for the hourly check
--recheckRe-enable update prompts you previously dismissed, then check
--no-updateSkip the update check for this launch

Launcher flags are read only when they come first; from the first other argument on, everything is forwarded unchanged to codex -p fugu. So codex-fugu resume resumes a session, codex-fugu "fix the failing test" starts one with a prompt, and codex-fugu --no-update resume combines both. Set CODEX_FUGU_NO_UPDATE=1 to disable update checks permanently, and CODEX_FUGU_NO_NOTICE=1 to silence the launcher’s occasional one-time notices.

Manual setup, file by file

Prefer to see exactly what you’re running? Three files wire Codex to Fugu. (You can also clone the repo yourself and run bash ~/.fugu/scripts/install.sh to do the same steps without the hosted endpoint.)

1. The model catalog~/.codex/fugu.json. Copy it from Sakana’s get-started page or the repo (configs/files/fugu.json). As of August 19, 2026 it defines four models: fugu (efforts high/xhigh), fugu-ultra-v1.1 (high/xhigh/max — the only model with a distinct max level), fugu-ultra-v1.0 (high/xhigh), and fugu-cyber (high/xhigh) — all with 1,000,000-token context windows. Note there is no unversioned fugu-ultra entry anymore: since an August update, the picker lists explicit versions so a new Ultra release never changes the model under you.

2. The profile~/.codex/fugu.config.toml:

model = "fugu"
model_reasoning_effort = "high"
model_provider = "sakana"
model_catalog_json = "~/.codex/fugu.json"

[features]
image_generation = false
apps = false

(The installer-deployed version of this file also sets remote_plugin = false in the features block — Sakana has pinned remote plugins off since Codex began enabling them by default; remove that line if you want upstream’s behavior.)

3. The provider block — appended to ~/.codex/config.toml (a workspace-local .codex/config.toml works too). The last three keys are stream-resilience hardening, which Sakana documents as verified safe because Fugu is stateless and retries are idempotent:

[model_providers.sakana]
name = "Sakana API"
base_url = "https://api.sakana.ai/v1"
env_key = "SAKANA_API_KEY"
wire_api = "responses"
stream_idle_timeout_ms = 7200000  # keep slow turns alive past Codex's ~5-min idle default
stream_max_retries = 5            # reconnect a dropped stream rather than failing the turn
request_max_retries = 4           # retry a transient HTTP failure rather than failing the turn

Then start Codex with your key in the environment:

SAKANA_API_KEY={your api key} codex -p fugu

It defaults to fugu; switch models any time with /model. That long stream timeout isn’t decoration, by the way — Fugu Ultra’s multi-agent turns can genuinely run long, and the default ~5-minute idle cutoff would kill them.

Backups: what’s saved and how to restore

Before switching your Codex version or first editing config.toml, the installer saves a timestamped copy of your existing setup to ~/.codex-backups/codex-config-<timestamp>/ — deliberately outside ~/.codex, so a backup survives even a full rm -rf ~/.codex. Each backup holds your config.toml and any *.config.toml, auth.json (kept at mode 0600), catalog JSON and Markdown files, the session index (state/memories/goals SQLite files), plus a manifest and SHA-256 checksums. The ten most recent backups are kept; tune with CODEX_BACKUP_KEEP and CODEX_BACKUP_ROOT, or skip with --no-backup.

Restore is two commands:

rsync -a --exclude MANIFEST.txt --exclude SHA256SUMS ~/.codex-backups/codex-config-<timestamp>/ ~/.codex/
codex doctor   # expect: config.toml parse: ok

Two safety details worth knowing. Fugu’s provider settings go into config.toml inside managed # >>> fugu:... >>> markers, so a re-deploy replaces only that block and leaves the rest of your config untouched. And after every edit the installer re-parses the file with codex doctor — if it no longer parses, the change is rolled back automatically.

Installer flags reference

FlagWhat it does
(none)Install and pin the Codex CLI, then deploy the Fugu config
--set-keyRe-prompt for and store the Sakana API key, no redeploy
--remove-configCleanly undo the deployed config
--pinned-version X.Y.ZPin a specific Codex version instead of the default
--forceDeploy even if the installed Codex version doesn’t match the target
--dry-runShow what would happen and change nothing
-y, --yesAssume yes, for non-interactive use

--dry-run deserves a highlight: it prints everything the installer would do without touching your system — run it first if you’re cautious about curl-pipe installs.

Quick troubleshooting

The three most common snags: a failed partial install (fix: rm -rf ~/.fugu and re-run the one-liner — a plain re-run reuses the broken clone); Codex not found or the wrong version running (the installer warns when its Codex isn’t on PATH or another install shadows the pinned one — follow the printed PATH fix); and authentication errors (rotate the key with codex-fugu --set-key). The full failure catalog, including where every file lives, is in the troubleshooting guide.

Why does Fugu pin a specific Codex version?

Sakana verifies the Fugu configs against one Codex version at a time (0.147.0 as of August 19, 2026) and updates the pin as upstream evolves. The launcher offers — never forces — a switch when your installed version differs, and it backs up your config and session index before any switch.

Will this break my existing Codex setup?

It’s designed not to: Fugu’s settings live in their own profile (fugu.config.toml) and a managed marker block inside config.toml, deployments are verified with codex doctor and rolled back if the file stops parsing, and everything touched is backed up to ~/.codex-backups first. –remove-config undoes the deployment cleanly.

How do updates work after install?

codex-fugu checks the repo for config updates at most once an hour and offers to apply them — it never blocks launch. Force a check with –check, re-enable dismissed prompts with –recheck, skip with –no-update, or disable permanently with CODEX_FUGU_NO_UPDATE=1.

Which models can I pick inside Codex?

As of August 19, 2026 the catalog lists fugu (default), fugu-ultra-v1.1, fugu-ultra-v1.0, and fugu-cyber (access-gated), all with 1M-token context. Switch with /model. Ultra is listed as explicit versions so a new release never silently changes your model.

Related: Fugu in Claude Code, the Windows setup, install troubleshooting, and the full API guide. Want to feel the models before committing to a setup? The browser playground takes two minutes.