Skip to content
/

oh-my-codex (scalarian)

oh-my-codex-scalarian · scalarian/oh-my-codex · ★ 65 · last commit 2026-04-01

A focused Codex-only workflow runtime with tmux team execution, MCP servers, and durable .omx/ state — the v2 vision without Claude bridge.

Best whenCodex is the first-party executor; no Claude bridge dilutes the surface area.
Skip ifClaude-to-Codex bridging (explicitly removed)
vs seeds
superpowershas a CLI runtime and MCP servers. Unlike…
Primitive shape 70 total
Skills 14 Subagents 6 Hooks 5 MCP tools 45
00

Summary

oh-my-codex (scalarian) — Summary

oh-my-codex v2 by scalarian is a now-archived (April 2026) fork of the OMX naming pattern, self-described as "not the old Codex-to-Claude bridge" but "a full Codex product" with a CLI, MCP families, agent catalog, plugin SDK, and tmux-aware team execution. With 65 stars and archived status, it represents a brief parallel effort that was active for approximately 3 months before being abandoned. The framework ships 14 skills, an omx binary built from a TypeScript monorepo (packages/cli, packages/core, packages/mcp-server), 5 hook handlers (SessionStart, PreToolUse, PostToolUse, UserPromptSubmit, Stop), and durable state under .omx/ mirroring the Yeachan canonical layout. The skills are notably more focused than the canonical project: architect, autoresearch, deep-interview, doctor, executor, hud, plan, research, review, reviewer, tdd, team, trace, ultrawork. Closest seed comparison: resembles superpowers in its skills-only behavioral framework but adds a CLI runtime and MCP servers; it is structurally derivative of the Yeachan canonical project with fewer components and no active maintenance.

01

Overview

oh-my-codex (scalarian) — Overview

Origin

Created by scalarian (@scalarian). Active from roughly January-April 2026; archived April 1, 2026. Appears to be an independent implementation of OMX v2 concepts that diverged from the canonical Yeachan project and was later abandoned. The README explicitly says "OMX v2 is not the old Codex-to-Claude bridge."

Note: The scalarian README references local paths like /Users/staticpayload/Mainframe/oh-my-codex/ suggesting it was developed by user "staticpayload" (not "scalarian") — the GitHub user and local path are inconsistent.

Philosophy

From README:

"OMX v2 is not the old Codex-to-Claude bridge. It is a full Codex product built around: durable .omx/ state, tmux-aware team execution, a real agent catalog, a plugin SDK plus Codex plugin bridge, a first-party hook pack for Codex hooks, CLI, MCP, docs, demos, and packaged assets in one repo."

"Codex is the first-party executor in v2. There is no Claude bridge in this release."

Key Differentiator from Yeachan

  • Codex-only: no Claude CLI worker support (unlike Yeachan which added Claude worker CLI)
  • Monorepo structure: packages/cli, packages/core, packages/mcp-server in separate packages
  • Slimmer skill set: 14 skills vs 46 in the canonical project
  • Archived: maintenance stopped April 2026

MCP Families (from README)

  • omx_task_* — task management
  • omx_state_* — state management
  • omx_memory_* — memory
  • omx_note_* — notes
  • omx_explore_* — exploration
  • omx_team_* — team lifecycle
  • omx_plugin_* — plugin management
  • omx_hook_* — hook status
  • omx_agent_* — agent catalog
02

Architecture

oh-my-codex (scalarian) — Architecture

Distribution

  • npm package (workspace, no binary in root package.json — binary lives in packages/cli)
  • Binary: omx (from packages/cli/dist/bin.js)
  • Status: archived as of April 1, 2026

Install

From README:

Install this to .codex - https://github.com/staticpayload/oh-my-codex/

Fallback:

npm install
npm run build
cd packages/cli && npm link
node packages/cli/dist/bin.js setup apply

Required Runtime

  • Node.js (version unspecified; assumed >= 18)
  • Codex CLI
  • tmux (for team mode)

Directory Tree

oh-my-codex/
├── packages/
│   ├── cli/            — omx binary (dist/bin.js)
│   ├── core/           — core runtime logic
│   └── mcp-server/     — MCP server implementations
├── crates/             — Rust (mirrored from Yeachan)
│   └── omx-explore/
├── plugins/
│   └── omx-product/    — Codex plugin bundle
├── hooks/
│   └── handlers/
│       ├── post-tool-use.mjs
│       ├── pre-tool-use.mjs
│       ├── session-start.mjs
│       ├── stop.mjs
│       └── user-prompt-submit.mjs
├── skills/             — 14 SKILL.md files
├── templates/
│   └── agents/
├── .agents/            — plugin marketplace metadata
└── demos/

Target AI Tools

  • Primary: OpenAI Codex CLI only
  • No Claude CLI worker support in v2

State Root

.omx/ in the project directory (same schema as Yeachan canonical):

  • .omx/hud-config.json
  • .omx/logs/
  • .omx/memory/
  • .omx/plans/
  • .omx/research/
  • .omx/sessions/
  • .omx/state/
  • .omx/team/
03

Components

oh-my-codex (scalarian) — Components

CLI Binary: omx (packages/cli)

Subcommands listed in README:

  • omx setup / omx setup --force / omx setup --dry-run / omx setup repair / omx setup uninstall / omx setup migrate-v1
  • omx doctor / omx hud
  • omx team init / omx team spawn executor / omx team queue / omx team claim / omx team complete / omx team review / omx team inbox / omx team logs / omx team shutdown
  • omx plugins validate / omx plugins pack / omx plugins install-local / omx plugins doctor
  • omx hooks install --presets=workspace-context,memory,safety,review / omx hooks status / omx hooks explain
  • omx explore index / omx explore refs / omx explore rename-preview / omx explore diagnostics
  • omx autoresearch init / omx session start / omx agents list|show|install|validate
  • omx version

Skills (14 total)

Skill Purpose
deep-interview Intent-first clarification loop for vague/risky work
ultrawork Default OMX flow: intent → plan → execute → verify
team tmux-based parallel execution
plan Durable planning state
architect Architecture/design decisions
executor Focused execution slice
reviewer Code review
review Review workflow
research Research workflow
autoresearch Bounded validator-gated research
tdd Test-driven development
trace Code investigation
hud HUD state display
doctor Environment health check

Hooks (5 handlers)

Handler Event
session-start.mjs SessionStart
user-prompt-submit.mjs UserPromptSubmit
pre-tool-use.mjs PreToolUse
post-tool-use.mjs PostToolUse
stop.mjs Stop

Hook presets: memory, safety, review, telemetry, workspace-context

Agent Personas (templates/agents/)

architect, planner, researcher, executor, reviewer, operator (from README)

MCP Families (packages/mcp-server)

  • omx_task_*, omx_state_*, omx_memory_*, omx_note_*, omx_explore_*, omx_team_*, omx_plugin_*, omx_hook_*, omx_agent_*

Plugin SDK

  • omx plugins init|pack|validate|install-local|list|enable|disable|doctor
  • Plugin schema: .codex-plugin/plugin.json
  • Marketplace bundle: plugins/omx-product/
05

Prompts

oh-my-codex (scalarian) — Prompts

Verbatim Excerpt 1: ultrawork/SKILL.md

Prompting technique: Goal-routing with explicit mode selection; state-first execution; minimal-mode preference

## Routing Rules

- ambiguous intent → `$deep-interview`
- clear but broad work → `$plan`
- one focused slice with known files → `$executor`
- parallel durable work → `$team`
- uncertain implementation pattern → `$research` or `$trace`

## Execution Policy

- start from the repo and `.omx/` truth, not chat memory
- prefer the smallest mode that can finish the job
- keep the runtime current as you go
- do not stop at a partial handoff unless the next owner is explicit

## State Contract

Ultrawork should leave behind:
- a current session
- a live or intentionally cleared planning state
- durable tasks with real status
- verification evidence in task notes or plan artifacts

Verbatim Excerpt 2: deep-interview/SKILL.md

Prompting technique: Sequential Socratic clarification without quantitative scoring; repo-first fact gathering

## Execution Policy

- Ask one question at a time.
- Ask only the highest-leverage unresolved question.
- Use repo facts before asking the user about codebase internals.
- Force clarity on non-goals and decision boundaries before handing off.
- Keep the interview moving toward a written artifact, not an endless conversation.

## Question Order

1. Why does this need to exist?
2. What should be true when it is done?
3. How far should it go?
4. What should explicitly stay out?
5. What may OMX decide without checking again?
6. What constraints or preferences are hard?

Key Difference from Yeachan Version

The scalarian deep-interview lacks the quantitative ambiguity scoring (threshold 0.15/0.20/0.30), the mathematical gating, and the omx question tmux pane integration. It is a simplified version of the same intent.

09

Uniqueness

oh-my-codex (scalarian) — Uniqueness

Differs From Seeds

Most similar to oh-my-codex-yeachan (canonical), from which it derives its architecture, state layout, and skill naming vocabulary. Within the seeds, closest to superpowers (skills-based behavioral framework) but adding a CLI runtime — however it lacks superpowers' comprehensive Iron Law prompting and TDD enforcement. Differs from agent-os in having a runtime binary and MCP servers. Differs from BMAD-METHOD in lacking persona-based role switching. The key distinction from the canonical oh-my-codex is its explicit Codex-only positioning ("no Claude bridge in v2"), reduced skill count (14 vs 46), monorepo architecture, and archived status.

Positioning

  • Derivative of oh-my-codex-yeachan; not the canonical package
  • More focused surface area (14 skills vs 46) — potentially easier to audit
  • Codex-only design choice removes the Claude-worker complexity
  • Archived April 2026 — no longer maintained

Note on Identity

The local paths in the README (/Users/staticpayload/Mainframe/oh-my-codex/) suggest the developer's GitHub handle is "staticpayload" but the repo is hosted under "scalarian" — likely a different account or fork transfer.

Observable Failure Modes

  • Archived: no bug fixes or updates
  • Local path leakage in README suggests the README was committed directly from dev machine without sanitization
  • Missing the ultragoal durable ledger that Yeachan added — cross-session handoff is weaker
  • No quantitative ambiguity scoring in deep-interview — interview quality is less rigorous

Canonical Status

Not canonical. The oh-my-codex npm package is owned by Yeachan-Heo's repo.

04

Workflow

oh-my-codex (scalarian) — Workflow

Canonical Flow

$ultrawork is the default OMX operating mode: intent → plan → execute → verify, with team escalation when parallel execution is justified.

$ultrawork
  ├── ambiguous intent → $deep-interview
  ├── clear but broad → $plan
  ├── focused slice → $executor
  ├── parallel durable → $team
  └── uncertain pattern → $research or $trace

Phases and Artifacts

Phase Skill Artifact Gate
Session start ultrawork .omx/ current state none
Clarification deep-interview .omx/plans/<phase>-requirements.md Clarity on: goal, in-scope, out-of-scope, acceptance criteria
Planning plan .omx/plans/ User approval
Research (opt.) autoresearch .omx/research/ Validator-gated
Execution executor Code changes none
Team execution team .omx/state/team/ Worker evidence
Verification (inline) Build/test output Required before close

Approval Gates

  1. Deep-interview convergence — must resolve goal, in-scope, out-of-scope, acceptance criteria before handoff
  2. Plan approval — before execution begins
  3. Worker evidence — team mode: orchestrator reads completion summaries before advancing

Deep-Interview (simplified vs Yeachan)

Question order:

  1. Why does this need to exist?
  2. What should be true when it is done?
  3. How far should it go?
  4. What should explicitly stay out?
  5. What may OMX decide without checking again?
  6. What constraints or preferences are hard?

No quantitative ambiguity scoring in this version (unlike Yeachan canonical).

State Contract

Ultrawork should leave behind:

  • a current session
  • a live or intentionally cleared planning state
  • durable tasks with real status
  • verification evidence in task notes or plan artifacts
  • an explicit "next action"
06

Memory Context

oh-my-codex (scalarian) — Memory & Context

State Storage

All state in .omx/ (mirrors Yeachan layout):

Path Content Persistence
.omx/plans/ Planning artifacts Project
.omx/research/ Research artifacts Project
.omx/sessions/ Session state Project
.omx/state/team/ Team worker state Project
.omx/memory/ Memory store Project
.omx/logs/ Session logs Project
.omx/hud-config.json HUD config Project

CLI State Commands

  • omx session start — start session
  • Session state persists to .omx/sessions/

MCP-Bridged Memory

omx_memory_* and omx_state_* MCP tool families provide structured access.

Context Compaction

Not explicitly described beyond .omx/ persistence. No ultragoal ledger (that is a Yeachan-specific component not present in this fork's skill set).

Cross-Session Handoff

Plans persist to .omx/plans/ for session resume. Less sophisticated than Yeachan's ultragoal ledger system.

07

Orchestration

oh-my-codex (scalarian) — Orchestration

Multi-Agent: Yes

$team skill enables tmux-based parallel execution:

  • Spawns worker Codex sessions in tmux panes
  • Coordination via .omx/state/team/ files and omx team api ...
  • omx team spawn executor / omx team queue / omx team claim / omx team complete

Orchestration Pattern

hierarchical (leader + N workers via tmux)

Isolation Mechanism

process (each worker is a separate Codex CLI process in a tmux pane)

Multi-Model

No — explicitly "Codex is the first-party executor in v2. There is no Claude bridge in this release."

Execution Mode

interactive-loop (session-based, tmux-aware)

Consensus Mechanism

None — leader reviews worker completions

Prompt Chaining

Yes: deep-interview → plan → executor → team is a chained workflow

Context Compaction

Handled by .omx/ filesystem persistence; no explicit compaction protocol documented.

Max Concurrent Agents

Unknown — depends on tmux and system resources

08

Ui Cli Surface

oh-my-codex (scalarian) — UI & CLI Surface

Dedicated CLI Binary

Binary: omx (packages/cli/dist/bin.js)
Install: via npm link or local package install
Is thin wrapper: No — own runtime

Subcommands

setup, doctor, hud, team (8 subcommands), plugins (4 subcommands), hooks (3 subcommands), explore (4 subcommands), autoresearch, session, agents (4 subcommands), version

HUD

tmux-integrated HUD (omx hud) — same pattern as Yeachan canonical.

Local Web Dashboard

None detected.

IDE Integration

None.

Observability

  • .omx/logs/ — session logs
  • omx explore diagnostics — system diagnostics
  • HUD state display

Demo Modules

  • demos/plugin-authoring/
  • demos/repo-marketplace/
  • demos/hook-pack/
  • demos/team-runtime/
  • demos/ultrawork/

Related frameworks

same archetype · same primary tool · same memory type

Claude-Flow / Ruflo ★ 55k

Eliminates single-agent context limits and sequential bottlenecks by orchestrating fault-tolerant swarms of specialized AI agents…

Hermes Agent (NousResearch) ★ 168k

Self-improving personal AI agent with closed learning loop, 7 terminal backends, and messaging gateway — not tied to any AI…

OpenCode ★ 165k

Terminal-first AI coding agent with multi-model routing, native desktop app, and a typed .opencode/ configuration system for…

OpenHands ★ 75k

Open-source AI software development platform (open-source Devin alternative) with Docker sandbox isolation, 77.6% SWE-bench…

DeerFlow ★ 70k

Long-horizon superagent that researches, codes, and creates by orchestrating parallel sub-agents with isolated contexts in Docker…

oh-my-openagent (omo) ★ 60k

Multi-provider AI agent orchestration for OpenCode: escape vendor lock-in by routing Sisyphus (Claude/Kimi/GLM) and Hephaestus…