Skip to content

ocx sync re-prints 'Removed unsupported reasoning efforts' + doctor hint on every sync, even when nothing changed #7004

Closed

Description

@tizerluo

Client or integration

Other

Area

CLI

Summary

ocx sync prints [opencodex] Removed unsupported reasoning efforts: minimal followed by [opencodex] Run ocx doctor for diagnosis and recovery. on every sync, including consecutive syncs where nothing changed. The clamp itself works correctly and is persisted in ~/.opencodex/codex-runtime-clamp.json, but the file is rewritten and the notice re-printed each run.

Expected: print the removal notice once (on first clamp, or only when the clamp set changes between syncs). Also, the ocx doctor suggestion is misleading in this context — doctor diagnoses environment/network issues (paths, proxy env, ChatGPT reachability) and has no clamp-related diagnostics or recovery, so the hint sends users down a dead end.

Reproduction

  1. Use a catalog that includes a model advertising the minimal reasoning effort (observed with hub/cursor-muse-spark-1.3; the codex CLI runtime supports low/medium/high/xhigh/max only).
  2. Run ocx sync → notice printed, clamp file written.
  3. Immediately run ocx sync again with no catalog/runtime change → the same two lines print again and codex-runtime-clamp.json is rewritten with a fresh updatedAt.

Observed consistently across 5 machines (3 × macOS arm64, 2 × Linux VPS) on opencodex 2.80.0 → 2.83.0 with codex CLI 0.161.0/0.162.1. A hub-side instance has recorded the same clamp shape since the 2.64 era for a different model (cursor/gemini-3.6-flash), so the mechanism predates 2.80; the per-sync repetition is what makes it noisy.

Version

2.83.0

Operating system

macOS 27 (arm64); also reproduced on Ubuntu Linux VPS

Provider and model

n/a — any catalog model advertising the minimal reasoning effort (e.g. hub/cursor-muse-spark-1.3)

Logs or error output

$ ocx sync
[opencodex] Removed unsupported reasoning efforts: minimal
[opencodex] Run ocx doctor for diagnosis and recovery.
   + 94 models appended to Codex catalog (/home/ops/.codex/opencodex-catalog.json)
Codex integration is OFF; catalog and models cache refreshed, Codex config untouched.

~/.opencodex/codex-runtime-clamp.json after each sync (identical content except updatedAt):

{
  "version": 1,
  "updatedAt": "2026-10-12T14:59:00.000Z",
  "runtimePath": "/home/ops/.local/bin/codex",
  "runtimeVersion": null,
  "removedEfforts": ["minimal"],
  "affectedModels": ["hub/cursor-muse-spark-1.3"]
}

Screenshots and supporting files

n/a

Redacted configuration

n/a — standard chained client (hub provider), no special configuration

Checks

  • I searched existing issues and documentation.
  • I removed secrets, tokens, account details, request credentials, and personal data.

Activity

  1. added
    bugSomething isn't working
    cliCLI, config inject, packaging flags
    on Oct 12, 2026
  2. Ingwannu commented on Oct 12, 2026

    @Ingwannu
    Owner

    Confirmed the per-sync rewrite/repeated notice path in current dev and reproduced both failures with synthetic fixtures (no live ocx sync or provider/native-client calls). Proposed fix: #7005, now Ready for review, with @lidge-jun requested.

    It reuses the existing persisted diagnostic, compares runtime path/version and order-independent clamp/model sets, suppresses only unchanged observations, preserves the projection callback, and permits clear-then-recurrence reporting. The misleading sync-only doctor hint is removed; actual effort clamping is unchanged.

    New regression: failure-before 4 pass / 2 fail; fix-after 6 pass / 0 fail. Existing clamp consumers: 6 pass / 0 fail. Structure/layout/size gates passed. Initial hosted typecheck found a readonly-array annotation mismatch; follow-up 5f81eab523 corrects that type and the new regression still passes. Current-head hosted Typecheck, docs-site-build and structure-gate results passed. Remaining selected CI jobs, independent review and Windows/macOS acceptance are still pending; skipped full native suites are not passing coverage. This issue stays open; a proposed PR is not a landed/released fix.

  3. lidge-jun commented on Oct 12, 2026

    @lidge-jun
    Owner

    Fixed on dev by #7005, landed through #7008 (merge a63267c134). Ships in 2.84.0.

  4. added a commit that references this issue on Oct 12, 2026
    419860b
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

    bugSomething isn't workingcliCLI, config inject, packaging flags

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions