Skip to content

Retire Gateway-owned Codex tool schemas and scheduling where the spike proves native behavior #59

Open

Description

@NOirBRight

Problem

CodexHub currently owns Codex-specific tool behavior beyond protocol adaptation:

  • hard-coded multi-agent schemas;
  • explicit tool injection/filtering;
  • transcript-derived lifecycle state;
  • forced next-action and tool_choice repair;
  • duplicate-spawn suppression;
  • synthesized lifecycle/tool events;
  • an independent scheduler and Dynamic DAG implementation.

Some behavior was introduced because third-party models did not call tool_search or did not reliably choose spawn/wait/close after results. It must not be deleted based on Codex++ or source inspection alone: Codex++ does not solve deferred discovery, search-disabled Codex does not automatically expose every Deferred tool, and #57 must distinguish visibility failures from provider/runtime/model failures.

src-python/subagent_dynamic_dag.py also contains production behavior gated by LEVEL3_DYNAMIC_DAG with hard-coded diagnostic nodes/outputs, which appears test-specific but must still be removed through an evidence-backed change.

Dependency gate

Blocked by #57 and #58. Do not implement until #57 has a maintainer GO/scoped PARTIAL decision and #58 has established the supported native-route contract.

For any behavior not explicitly covered by those decisions, preserve the current compatibility implementation. If deciding whether a behavior is necessary requires new live evidence, create a narrower spike first; do not delete it speculatively in this issue.

Scope

Only for provider/model/protocol/tool-class combinations proven safe:

  • make live Codex schemas/history the source of truth;
  • remove hard-coded schema replacement where native search or proven live direct exposure works;
  • remove or disable-by-default Gateway-owned spawn/wait/close scheduling where Codex runtime plus the model completes the lifecycle;
  • stop forcing next calls or synthesizing tool calls/events as a normal orchestration mechanism;
  • preserve generic request-scoped namespace/name/call-id mapping only where required by the upstream protocol;
  • move LEVEL3_DYNAMIC_DAG and hard-coded diagnostic nodes out of production code, or replace their purpose with replay fixtures;
  • retain evidence-backed compatibility behind an explicit provider/model/tool-class mode with telemetry and rollback.

Do not mix native route enablement from #58 into this cleanup.

Removal evidence ledger

Before deleting or disabling each behavior, record:

Absence of a failure in unrelated tests is not sufficient evidence.

Acceptance criteria

  • Every removed behavior has an entry in the evidence ledger.
  • Unknown, untested, or inconclusive combinations retain compatibility behavior.
  • Live Codex schemas/history replace hard-coded copies only on approved capability classes.
  • Gateway no longer forces or fabricates lifecycle calls only on approved native paths.
  • Search-enabled and search-disabled behavior are not treated as equivalent.
  • subagent_dynamic_dag.py no longer puts marker-driven diagnostics in production routing.
  • Tools, namespaces, history, tool choice, call ids, SSE, completion notifications, and parent aggregation remain covered.
  • Diagnostics distinguish discovery, provider loss, runtime behavior, and model orchestration weakness.
  • Rollback to compatibility mode is documented.

Required verification

python -m pytest tests/test_codex_semantic_adapter.py tests/test_subagent_protocol.py tests/test_subagent_state.py tests/test_subagent_scheduler.py tests/test_subagent_dynamic_dag.py tests/test_routing.py tests/test_chat_completions_gateway.py
python -m pytest
python scripts/report_quality_gates.py

Related

Activity

  1. NOirBRight commented on Jul 11, 2026

    @NOirBRight
    OwnerAuthor

    Planning update (2026-07-11): GitHub now records #57 and #58 as native blocking dependencies. This issue is on the Capability-driven routing rollout milestone. Target window is Aug 10–14. Compatibility behavior remains for every unknown, failed, or unapproved scope.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestneeds-infoWaiting on reporter for more informationwayfinder:taskWayfinder implementation task

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions