Skip to content

Preserve OpenCode tool-result history on third-party transparent Responses routes #193

Closed

Description

@NOirBRight

Outcome

Preserve OpenCode client-owned tool history on compatible third-party transparent Responses routes so Volc GLM-5.2 consumes one successful tool result and completes instead of repeating the tool loop.

Dependencies

Native blocker: #190. The #190 calibration records the stable 0.1.6 OpenCode/Volc failure as excessive_tool_loop; this Issue's candidate is the first required all-green twelve-round baseline. It consumes production-managed client configuration from #194 through #190.

Required design

  • Determine the real OpenCode endpoint, managed selector, canonical model, downstream format, and upstream format from Expose headless managed-client config materialization for isolated runners #194 materialization/readback plus sanitized Gateway diagnostics before changing payload handling.
  • Preserve compatible client-owned standard Responses function_call and paired function_call_output items, call IDs, names, arguments, outputs, status, and ordering byte- or semantic-transparently on same-format routes.
  • Restrict rewriting/normalization to records proven Codex-internal or explicit format-conversion paths. Preserve the established compatibility behavior for internal multi-agent, node REPL, compaction, tool-search, and native apply_patch records.
  • Do not globally take ownership of external-client tool loops, retries, terminals, or fallback policy.
  • Add bounded observation/error classification so repeated successful duplicate calls fail closed as excessive_tool_loop before hundreds of rounds, without masking the transparent-payload defect.

Acceptance

  • Focused tests prove a standard function call and paired result remain structured, ordered, and paired through the real transparent Volc Responses boundary.
  • Compatible transparent payloads remain byte- or semantic-identical; translation occurs only on explicit Responses/Chat conversion paths.
  • Model remap, store policy, supported message normalization, developer-role policy, boolean JSON Schema normalization, and genuine internal-item compatibility remain unchanged.
  • No provider/model fallback, no broad removal of internal protections, no new Responses/Chat conversion, and no global tool-loop ownership.
  • Real OpenCode 1.18.4 uses the production-managed Volc glm-5.2 selector/route, executes one random sentinel read-only tool, consumes its non-empty result, and produces one terminal completion with request_complete=200, no duplicate call/output, fallback, or reconnect.
  • The full twelve-round matrix is all green on the same candidate SHA. Official rounds use gpt-5.6-luna; third-party rounds use Volc glm-5.2; no Kimi K3, Sol, Ollama, or substitute provider is allowed.

Hotset and gates

Expected code boundary: src-python/codex_proxy.py and focused routing tests; bounded-loop runner tests may update the #190 scripts/fixtures after #190 has merged.

Required gates: targeted tests, full python -m pytest -q, git diff --check, report-only quality gates, exact-SHA Actions, strict heavy review, Debug build, and authoritative VM evidence. Squash to dev only.

Activity

  1. added
    bugSomething isn't working
    needs-triageMaintainer needs to evaluate this issue
    P1Priority 1: current iteration goal
    on Jul 20, 2026
  2. NOirBRight commented on Jul 20, 2026

    @NOirBRight
    OwnerAuthor

    Regression provenance confirmed:

    • The transparent-path interception was introduced by b0a7c69b1692b8633c4c2b45c0e4e03d7a1e2088 (fix: sanitize OpenAI compaction items across all request paths).
    • That commit's stated purpose was to prevent OpenAI-only compaction, compaction_trigger, and other genuinely internal items from reaching third-party providers after model switching.
    • It reused _rewrite_internal_input_items() on every non-official transparent request.
    • The pre-existing INTERNAL_INPUT_ITEM_TYPES set also contains standard Responses function_call and function_call_output, so the sanitizer's classification boundary is wider than the problem it was meant to solve.

    The fix should narrow semantic ownership, not special-case OpenCode by user agent:

    • Standard function_call / function_call_output remain structured by default on same-format transparent routes.
    • Only proven Codex-only item types are globally sanitized.
    • Named Codex-specific function families (multi-agent, node REPL, etc.) and explicitly selected codecs retain their targeted adapters.
    • Add regression coverage showing compaction remains sanitized while an adjacent ordinary function call/result pair is byte/structure preserving.
  3. added
    ready-for-agentFully specified, ready for an AFK agent
    wayfinder:taskWayfinder implementation task
    tier:heavyOrchestrator provider tier: heavy
    and removed
    needs-triageMaintainer needs to evaluate this issue
    on Jul 21, 2026
  4. NOirBRight commented on Jul 21, 2026

    @NOirBRight
    OwnerAuthor
    {
      "contract": {
        "acceptance": [
          "The real OpenCode-to-Gateway endpoint and format are demonstrated from production-managed configuration and sanitized diagnostics before payload handling changes.",
          "A standard Responses function_call and paired function_call_output remain structured, paired, ordered, and byte- or semantic-equivalent across the transparent Volc Responses boundary.",
          "Model remap, store policy, supported message normalization, developer-role policy, boolean JSON Schema normalization, and genuine Codex-internal compatibility remain unchanged.",
          "Repeated successful duplicate calls terminate within a tested bound as excessive_tool_loop without fallback, broad internal-protection removal, or new Responses/Chat conversion.",
          "No Issue #190 runner, fixture, documentation, GUI, credential, or host-evidence path changes occur in this implementation.",
          "After Issue #190 merges, the exact final candidate is refreshed on dev and the complete twelve-round matrix is all green: Official gpt-5.6-luna and Volc glm-5.2 only, one real sentinel read, one terminal, one request_complete=200, and no fallback, duplicate output, or unclassified reconnect.",
          "Targeted tests, full python -m pytest -q, git diff --check, report-only quality gates, exact-SHA Actions, strict heavy review, Debug build, and authoritative host evidence pass for the final refreshed SHA."
        ],
        "change_claims": {
          "paths": [
            "src-python/codex_proxy.py",
            "tests/test_routing.py",
            "tests/test_chat_completions_gateway.py"
          ],
          "resources": [
            "gateway-transparent-responses"
          ]
        },
        "dependencies": {
          "dispatch_after": [
            190
          ],
          "merge_after": [
            190
          ]
        },
        "design": [
          "Implement the OpenCode/Volc transparent Responses tool-history correction now from the current dev base, using the production managed-client seam already merged by Issue #194 to determine endpoint, selector, canonical model, and route format.",
          "Keep this implementation write set strictly in the Python Gateway and focused routing tests. Do not edit the Issue #190 runner, fixtures, or host evidence resources; the existing foundation supplies the later real-client gate.",
          "Preserve compatible standard Responses function_call and paired function_call_output items, identifiers, names, arguments, outputs, status, and ordering byte- or semantic-transparently on same-format routes. Restrict normalization to Codex-internal records or explicit protocol conversion.",
          "Add bounded excessive_tool_loop classification without taking global ownership of external-client tool loops, retries, terminals, or fallback policy.",
          "Implementation may run in parallel with Issue #190. Squash merge remains blocked on Issue #190; after that merge, update the branch to dev and regenerate every final-SHA check, review, Debug build, and twelve-round evidence."
        ],
        "difficulty": "heavy",
        "done_when": [
          "python -m pytest -q tests/test_routing.py tests/test_chat_completions_gateway.py",
          "python -m pytest -q",
          "git diff --check",
          "python scripts/report_quality_gates.py (report-only)",
          "Exact-SHA GitHub Actions and strict heavy review pass after final dev refresh",
          "Authoritative machine-bound host twelve-round matrix is all green on the same final SHA after Issue #190 merges"
        ],
        "priority": "P1",
        "risk": "strict",
        "sha256": "1ff14dbee06ecd94fb43a834b557450b186b62b69343c35bf0718549dbf1e46f",
        "unresolved_decisions": []
      },
      "dispatch": {
        "attempt": 1,
        "base_sha": "e424f659d158a0a71bb60061f56487051fc3e346",
        "branch": "work/issue-193",
        "claimed_at": "2026-07-22T15:35:40.681528Z",
        "contract_sha256": "1ff14dbee06ecd94fb43a834b557450b186b62b69343c35bf0718549dbf1e46f",
        "creator_agent_id": "fc91861e-6478-4d4e-8019-d7d0cff5c451",
        "generation": 1,
        "id": "dispatch-issue-193-a1",
        "status": "running",
        "worker_agent_id": "17fdf2ea-2227-4a37-bcf9-3bbf32ed53b8",
        "workspace_id": "wks_257846746b055857"
      }
    }
  5. added
    orch:readyOrchestrator V6: valid hashed contract is complete and dispatchable
    on Jul 21, 2026
  6. 2 remaining items

  7. added
    orch:readyOrchestrator V6: valid hashed contract is complete and dispatchable
    and removed
    orch:readyOrchestrator V6: valid hashed contract is complete and dispatchable
    orch:activeOrchestrator V6: claimed Worker is active or rework is in progress
    on Jul 22, 2026
  8. added
    orch:activeOrchestrator V6: claimed Worker is active or rework is in progress
    and removed
    orch:readyOrchestrator V6: valid hashed contract is complete and dispatchable
    on Jul 22, 2026
  9. added and removed
    ready-for-agentFully specified, ready for an AFK agent
    orch:activeOrchestrator V6: claimed Worker is active or rework is in progress
    on Jul 25, 2026
  10. NOirBRight commented on Jul 25, 2026

    @NOirBRight
    OwnerAuthor

    Phase 0 frontier reconciliation complete.

    No additional code change is required for this ticket. Closing it unlocks the bounded #18 implementation slices beginning with #221.

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

    P1Priority 1: current iteration goalbugSomething isn't workingready-for-humanRequires human implementationtier:heavyOrchestrator provider tier: heavywayfinder:taskWayfinder implementation task

    Projects

    No projects

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions