Skip to content

Plan Codex-base substrate migration for Every Code #384

@shiny-code-bot

Description

@shiny-code-bot

Finish Line

Every Code has a reviewable Codex-base substrate migration plan that replaces the raw spike with scoped PR slices, clarifies the future role of code-rs and codex-rs, and prevents new work from landing on the wrong base.

Current Status

State: Rescoped from "Codex-base substrate migration for Every Code" to "Codex CLI fork foundation plus narrow Every Code overlays." The substrate work landed; the active risk is stale planning/docs language that still sounds product-first.

Decision update, 2026-06-06:

  • Codex CLI compatibility is the default direction for app-server/session/protocol/config/TUI behavior.
  • Every Code is moving into maintenance mode as a standalone product direction.
  • The repo should be treated as a Codex CLI fork that layers selected Every Code capabilities on top only when they remain needed and are validated.
  • code-rs is the editable fork implementation; codex-rs remains the read-only upstream provenance mirror until a new issue changes that role.
  • Fork deltas should be small, reviewable, and easy to rebase/refresh from upstream Codex CLI.

Landed foundation:

Remaining alignment work:

Next action:

  • Track the docs/policy cleanup as a small explicit issue so future agents stop inheriting the wrong north star.

Acceptance Criteria

  • Decide and document the code-rs / codex-rs roles for the Codex-base migration.
  • code-rs can build from a Codex-base workspace as the code binary with ./build-fast.sh.
  • Imported upstream crates keep codex-* names unless there is a specific Every Code product reason to alias/rename.
  • Every Code-only additions have a documented code-* port strategy.
  • CODE_HOME takes precedence over CODEX_HOME; no-env default is ~/.code.
  • No code-rs crate depends on sibling ../codex-rs; the path-dependency guard enforces the chosen policy.
  • .github/github.json, AGENTS/repo guidance, and docs/upstream-import-policy.md describe the new substrate/mirror roles.
  • Active issues that touch app-server/session/protocol/TUI/remote-inbox/release identity are linked, blocked, or marked independent.
  • The raw spike is decomposed into reviewable PR slices and is not merged wholesale.

Relationships

Metadata

Metadata

Assignees

No one assigned

    Labels

    planDurable planning issueplan:waitingPlan is waiting on non-issue evidence or decision

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions