[Feature]: add Muse Code subscription routing through a process-backed MSP adapter

[SOSANA]

Area

Multiple areas

What are you trying to accomplish?

Use an active Muse Code subscription as an explicit, subscription-backed model route for Codex CLI, Codex Desktop, and other OpenCodex-connected clients without silently sending those requests through Meta Model API pay-as-you-go billing.

The desired user workflow is:

1. Install the official muse CLI.
2. Sign in through muse login with the Meta account that owns a Muse Code subscription.
3. Let OpenCodex expose a clearly labeled Muse Code route to compatible clients.
4. Select a model such as muse-code/muse-spark-1.2 in Codex.
5. Have the request consume Muse Code plan allowance, preserving the subscription's current and weekly usage windows.
6. Keep any separately configured Meta Model API key route visibly distinct and pay-as-you-go.

This is primarily a provider-adapter and authentication-provenance request, with related proxy, streaming, tool, lifecycle, catalog, usage, and dashboard implications.

What prevents this today?

OpenCodex currently treats Meta Muse models as a normal HTTP API-key provider. On OpenCodex 2.39.0, the configured route is equivalent to:

provider: meta-model-api
adapter: openai-chat
base URL: https://api.meta.ai/v1
authentication: API key
models:
  - muse-spark-1.1
  - muse-spark-1.2
  - muse-spark-1.2-contributor

That route works technically, but Meta records it under Model API pay-as-you-go usage. It does not consume the Muse Code subscription merely because the same Meta account owns both.

Meta's subscription documentation states that:

• Muse Code subscriptions are flat-rate usage for Muse Code rather than per-token API billing.
• The subscription applies through the Muse Code CLI while signed in with the Meta Model API account.
• The subscription credential is for Muse Code only.
• Additional API keys under the Model API account are billed pay-as-you-go.

Source: https://dev.meta.ai/docs/muse-code/subscriptions

The official CLI exposes a process boundary that appears intended for host integrations:

muse serve — serve an MSP session host over stdio

The embedded schema advertises a session-oriented command plane including session/*, turn/*, model/list, view/*, approval/*, and userInput/*. However, OpenCodex's current adapter registry has HTTP/provider wire adapters such as openai-chat, openai-responses, anthropic, google, kiro, and cursor; it has no MSP, stdio, or general process-backed provider adapter. Its current OAuth controllers also do not include Muse/Meta account login.

As a result, none of these current approaches satisfies the workflow:

• Pointing OpenCodex at https://api.meta.ai/v1 uses API-key billing.
• Importing or extracting Muse account tokens would cross an unsupported credential boundary and should not be done.
• Running muse separately uses the subscription but does not make it an OpenCodex/Codex model route.
• Wrapping one-shot muse exec calls as plain text loses session continuity, tool calls, approvals, cancellation, model configuration, and authoritative streaming semantics.
• Exposing Muse only as an MCP tool would make it a tool used by another primary model, not a selectable Muse-backed coding agent.

The important failure mode is billing ambiguity. A catalog row named only muse-spark-1.2 can look subscription-backed even when it is actually the separately metered Model API route.

What should OpenCodex do?

Provide a first-class, explicitly labeled Muse Code subscription integration that launches and communicates with the official authenticated Muse CLI instead of reusing a Meta Model API key.

Observable behavior should include the following.

1. Explicit credential and billing provenance

• Present the subscription route as something like Muse Code subscription via Muse CLI.
• Keep it separate from Meta Model API · pay-as-you-go even when both offer the same model ID.
• Never imply that an API-key route consumes subscription allowance.
• Never silently fall back from the subscription route to a Meta API key.
• If an optional fallback is ever supported, require explicit configuration and surface the billing boundary before it is enabled and in per-request logs afterward.

This should follow the same provenance principle described in #1213: a unified catalog must not hide a meaningful change in credential or billing source behind identical model names.

2. Official Muse CLI account boundary

• Use the installed muse executable and its own Meta account session.
• Do not read, export, copy, persist, or forward Muse OAuth/access/refresh credentials into OpenCodex storage.
• Provide an authentication-status check that can distinguish at least:
  • Muse CLI not installed;
  • installed but not logged in;
  • logged in without an eligible subscription;
  • eligible subscription available;
  • subscription usage limit reached;
  • account session requires reauthentication.
• When login is required, direct the user to the official muse login flow rather than collecting Meta credentials in OpenCodex.

3. Process-backed MSP session integration

• Launch muse serve as a supervised local child process or equivalent official Muse host boundary.
• Translate OpenCodex's downstream Responses API contract into MSP sessions and turns without flattening the interaction into one-shot text completion calls.
• Preserve:
  • conversation/session affinity;
  • streaming text and status events;
  • model selection and supported reasoning-effort configuration;
  • tool declarations and tool results where the protocols permit them;
  • approval and user-input requests;
  • cancellation and interruption;
  • session rotation and recovery;
  • image or other supported multimodal inputs;
  • authoritative terminal completion and error states.
• Bound process startup, idle, turn, cancellation, and shutdown behavior so a dead or wedged Muse host cannot leave Codex requests hanging indefinitely.

If MSP cannot faithfully represent a required Codex Responses behavior, fail with a named compatibility error instead of silently degrading the request.

4. Catalog and client behavior

• Expose plan-backed models under a distinct namespace, for example:

muse-code/muse-spark-1.2

• Preserve the existing API-backed namespace separately, for example:

meta-model-api/muse-spark-1.2

• Make GET /v1/models, the generated Codex catalog, CLI output, dashboard rows, and request logs agree on the selected provenance.
• Allow the subscription route to be selected from both Codex CLI and Codex Desktop through the normal OpenCodex catalog path.
• Do not require the user to expose a Meta API key just to use the subscription route.

5. Usage and observability

• Report Muse plan usage as subscription allowance, not estimated token cost.
• If the Muse host exposes current-window and weekly-window usage, show those windows distinctly from pay-as-you-go spend.
• Tag request logs with safe route metadata such as:

provider=muse-code
auth=meta-account-session
billing=subscription
transport=msp-stdio

• Never log account tokens, browser authorization codes, raw credential stores, or unsafe account identifiers.
• Make it possible to prove that a request used the subscription route without inspecting secrets.

6. Security and policy boundaries

• Keep the Muse child process local by default.
• Preserve OpenCodex's existing loopback and client-admission protections.
• Treat workspace trust, shell access, filesystem access, sandbox posture, and network posture as explicit host configuration rather than protocol assumptions.
• Do not enable muse serve --trust-workspace, disable its sandbox, or broaden network/filesystem access implicitly.
• Document which process owns tool execution and approval decisions so the same tool is not executed once by Muse and again by Codex/OpenCodex.
• Verify the proposed integration against Meta's current Muse Code subscription terms before declaring it supported.

7. Failure and recovery behavior

Return clear, non-secret-bearing errors for at least:

• executable missing or unsupported Muse version;
• invalid or expired Meta account session;
• no eligible Muse Code subscription;
• plan window exhausted;
• incompatible MSP schema or protocol version;
• child-process startup failure;
• child-process crash during a turn;
• stalled stream or cancellation timeout;
• unsupported tool, modality, or Responses feature;
• user-selected subscription route with only an API key available.

Restart or retry behavior must be bounded and must not change billing provenance.

Example usage or interface

One possible CLI shape is shown below. The exact option names can follow existing OpenCodex conventions, but the user-visible separation between subscription and API billing is required.

# Authenticate through the official client. OpenCodex does not receive the token.
muse login

# Register or enable the process-backed subscription provider.
ocx provider add muse-code \
  --adapter muse-msp \
  --command muse \
  --command-arg serve

# Confirm executable, login, subscription eligibility, model discovery,
# protocol compatibility, and billing provenance without consuming API-key credit.
ocx provider test muse-code

# Show a redacted status projection.
ocx provider show muse-code --json

# Use the subscription-backed route from Codex CLI.
codex --model muse-code/muse-spark-1.2

Expected status projection:

{
  "name": "muse-code",
  "adapter": "muse-msp",
  "transport": "stdio",
  "authentication": "Meta account session owned by Muse CLI",
  "billing": "Muse Code subscription",
  "loggedIn": true,
  "subscriptionEligible": true,
  "models": ["muse-spark-1.2"]
}

The existing API route remains separately visible:

{
  "name": "meta-model-api",
  "adapter": "openai-chat",
  "baseUrl": "https://api.meta.ai/v1",
  "authentication": "API key",
  "billing": "pay-as-you-go",
  "models": [
    "muse-spark-1.1",
    "muse-spark-1.2",
    "muse-spark-1.2-contributor"
  ]
}

The dashboard and picker should use provenance-aware labels, for example:

Muse Spark 1.2 · Muse Code subscription
Muse Spark 1.2 · Meta Model API pay-as-you-go

Alternatives or workarounds

Continue using the Meta Model API key

This already works in OpenCodex, but it incurs per-token API charges and does not satisfy the subscription workflow.

Run Muse Code separately

This is the only currently verified subscription-backed route. It does not make Muse a selectable model inside Codex CLI/Desktop or other OpenCodex clients.

Invoke muse exec from a shell script or MCP tool

This can use the official CLI account session for bounded calls, but Muse becomes a secondary tool rather than the primary coding agent. A naive one-shot wrapper also loses session, tool, approval, interruption, and streaming semantics.

Extract the Muse account token and use it as an OpenCodex bearer token

This should not be implemented. It would bypass the documented credential boundary, create token-refresh and storage risks, and may violate Meta's intended subscription usage contract.

Build a standalone Responses-to-MSP proxy outside OpenCodex

This could prove the translation experimentally, but it would duplicate OpenCodex routing, lifecycle, catalog, logging, and security responsibilities. If the integration is supportable, OpenCodex is the more coherent long-term owner.

Additional context

Verified environment

The following was verified on September 1, 2026:

OpenCodex installed: 2.39.0
OpenCodex latest npm: 2.39.0
Muse Code CLI: 1.0.1 (1.0.1-R2006.1)
Operating system: Linux x86_64

Direct evidence:

• ocx provider show meta-model-api --json reports adapter: openai-chat, baseUrl: https://api.meta.ai/v1, and API-key presence.
• A minimal request through the raw OpenCodex/Meta route appeared under Meta Model API pay-as-you-go usage.
• After muse login, a minimal muse exec --model muse-spark-1.2 request completed successfully.
• The Meta usage dashboard then exposed Muse Code subscription-window consumption separately from pay-as-you-go spend.
• The pay-as-you-go balance did not change across the direct Muse CLI subscription smoke request.
• muse serve --help confirms an MSP session host over stdio.
• muse schema documents a session/turn/model/view/approval/user-input command plane embedded in the installed binary.
• OpenCodex 2.39.0's adapter registry does not contain an MSP, ACP, stdio, Muse CLI, or generic process-backed provider.
• OpenCodex's current sidecar surface is limited to web and vision model sidecars and does not host an external full coding agent.

No credentials, account identifiers, project IDs, payment details, prompts from private work, or personal paths are included in this report.

Related issue and provenance precedent

• [Feature/UX]: add additive Claude Desktop catalog mode with honest native/OpenCodex switching #1213 documents the requirement not to simulate subscription-backed access with a separately billed API credential and asks that unified catalogs expose meaningful provider/credential provenance.

No open issue was found for Muse Code subscriptions, Meta subscription routing, MSP adapters, stdio/process-backed providers, or muse serve integration before filing this proposal.

Suggested delivery slices

This likely benefits from staged delivery rather than one large change:

1. Read-only Muse executable, version, login, eligibility, and model discovery probe.
2. MSP schema/version negotiation and supervised process lifecycle.
3. Single-session text streaming through an explicit experimental provider.
4. Cancellation, interruption, terminal errors, and restart recovery.
5. Tool, approval, user-input, and multimodal compatibility.
6. Multi-session affinity, bounded concurrency, and lifecycle tests.
7. Catalog, picker, dashboard, usage, and billing-provenance UI.
8. Documentation, migration guidance, and a no-API-fallback security review.

Non-goals

• Do not scrape or copy credentials from Muse storage.
• Do not claim that Meta Model API keys are subscription-backed.
• Do not silently convert subscription exhaustion into API charges.
• Do not make Muse Code the OpenCodex default automatically.
• Do not weaken Muse or OpenCodex sandbox, approval, workspace-trust, or network defaults.
• Do not expose a local account-backed Muse host remotely without a separate authenticated multi-user security design.

Acceptance criteria

• A supported process-backed Muse integration uses the official muse account session without OpenCodex owning the Meta credential.
• Codex CLI and Codex Desktop can select a distinctly namespaced Muse subscription route from the OpenCodex catalog.
• A subscription-backed request is observable as plan usage and does not increment Meta Model API pay-as-you-go spend.
• The existing Meta API-key provider remains available only under explicit pay-as-you-go provenance.
• No automatic fallback crosses from subscription to API billing.
• Missing login, missing subscription, exhausted plan, protocol mismatch, process failure, and unsupported capabilities produce clear bounded errors.
• Streaming, cancellation, session affinity, terminal completion, and restart behavior have focused regression coverage.
• Tool and approval ownership is explicit and double execution is prevented.
• Logs, config projections, and error output never expose Muse or Meta credential material.
• Catalog, /v1/models, generated Codex metadata, dashboard, and request logs agree on billing provenance.
• Documentation states the supported Meta/Muse boundary and links to current upstream subscription documentation.
• The integration is verified against current Muse Code subscription terms before being advertised as supported.

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.

[github-actions]

_{Automated translation bookkeeping — detected language: Korean.}

[lidge-jun]

리뷰 · 우선순위 49 / 80

설명

이 이슈는 OpenCodex가 Muse Spark를 Codex에서 고를 수 있게 해 달라는 말이 아닙니다. 이미 HTTP로 고를 수 있습니다. 보고자 SOSANA가 원하는 것은 다른 청구입니다. 공식 muse CLI를 설치하고, muse login 으로 Meta 계정에 들어간 뒤, Codex에서 muse-code/muse-spark-1.2 처럼 구독 길이라고 적힌 모델을 고르면, 그 요청이 Muse Code 구독 한도만 깎이게 하자는 요청입니다. Meta Model API 키로 쓰는 길은 남겨 두되, 이름과 로그와 대시보드가 구독 길과 같아 보이면 안 됩니다. 구독이 끝나도 API 키로 조용히 넘어가면 안 됩니다. Muse 토큰을 OpenCodex가 꺼내 저장하면 안 됩니다.

지금 checkout HEAD는 88c4275 입니다. 제목은 feat(combo): adapt reasoning effort to target capabilities (#2731) (#3190) 입니다. 패키지는 2.40.0 입니다. 이 열차는 콤보 노력 사다리, 용량·쿼터, remote-hub 후속입니다. 자식 프로세스로 muse serve 를 띄워 MSP를 말하는 새 어댑터 가문은 이 열차가 최적화하는 일이 아닙니다. types.ts 자동 분할 배럴과도 무관합니다. 이슈이므로 close-don't-rebase 대상이 아닙니다.

오늘 Muse를 쓰는 OpenCodex 길은 HTTP API 키입니다. 이슈가 적은 meta-model-api + openai-chat + https://api.meta.ai/v1 는 저장소에 박힌 기본 제공자가 아닙니다. 사용자가 API 키로 붙인 openai-chat 경로입니다. 그 길은 요청을 보내 응답을 받습니다. 그러나 Meta는 그걸 Model API 쓴 만큼 내는 청구로 잡습니다. 같은 Meta 계정이 Muse Code 구독을 갖고 있어도, API 키 요청은 구독 한도를 깎지 않습니다. 보고자가 2026-09-01에 확인한 대로, 공식 muse exec 만 구독 창을 깎고 pay-as-you-go 잔액은 그대로였습니다. HTTP 길이 동작한다고 해서 구독 길이 이미 있는 것이 아닙니다.

HEAD에 이미 있는 Muse Spark 행도 HTTP입니다. src/providers/registry.ts 는 Command Code 이미지 모델로 meta/muse-spark-1.2 와 meta/muse-spark-1.2-contributor 를 적습니다. src/providers/command-code-efforts.ts 는 그 아이디에 low부터 max까지 노력 사다리를 둡니다. OpenCode Go 제공자는 muse-spark-1.2-contributor 를 openai-responses 로 보내고, 컨텍스트 창을 1_048_576 으로 적습니다. src/adapters/openai-responses.ts 의 stripMuseSparkUnsupportedWebSearchFields 는 그 contributor 아이디만 골라 web_search 의 search_content_types 필드를 뺍니다. 모두 HTTP 어댑터 위의 모델 보정입니다. Muse Code 구독 세션이 아닙니다.

어댑터 레지스트리 src/adapters/registry.ts 의 와이어는 command-code, openai-chat, ollama-native, anthropic, openai-responses, google, kiro, cursor 입니다. AgentRouter(#2843)는 HTTP 호환 헬퍼이고, ollama-native(#2863)는 로컬 REST 입니다. Cursor는 protobuf-over-HTTP 이고, Kiro는 HTTP 위에 completion tool 을 얹습니다. 둘 다 자식 프로세스 세션 호스트가 아닙니다. MSP, stdio 제공자, muse serve, muse-code, muse-msp 파일은 src에 없습니다. 사이드카는 web-search 와 vision 뿐이고, 외부 코딩 에이전트를 키지 않습니다. Cursor 와 Command Code 안의 spawn·execFile 은 도구 실행용입니다. 제공자 세션을 붙잡는 자리가 아닙니다.

그래서 이 이슈를 지금 HTTP Muse 행과 같다고 닫으면 안 됩니다. 요청의 핵심은 청구 출처입니다. #1213 이 이미 같은 원칙을 적었습니다. 카탈로그에 같은 모델 이름을 써 두고, 뒤에는 구독이 아니라 따로 청구되는 API 자격으로 보내면 안 됩니다. #1213 은 Claude Desktop 이야기이지만, 이름만 같고 청구가 다른 길을 숨기지 말라는 점은 여기와 같습니다. 구현하려면 한 PR이 아니라 여러 조각입니다. 실행 파일·로그인·구독 자격 조사, 자식 프로세스 수명, Responses 계약과 MSP session/turn/approval/userInput 번역, 카탈로그 출처 표시, API 키로 조용히 넘어가지 않는 보안 리뷰. 지금 버그·랜딩 열차 위에 올리면 범위가 커집니다. 점수는 49입니다. 청구 출처 구멍은 진짜이지만, 새 어댑터 가문이고 현재 HEAD는 이 일을 다음 칸으로 두지 않았습니다.

경로 src/adapters/registry.ts ADAPTER_REGISTRY - MSP·stdio·muse-msp 자리가 없습니다. 이 이슈를 걸 기존 어댑터가 없습니다
경로 src/providers/registry.ts meta/muse-spark-1.2 · meta/muse-spark-1.2-contributor · OpenCode Go muse-spark-1.2-contributor - 이미 HTTP Muse Spark 행입니다. 구독 길을 같은 아이디로 올리면 카탈로그가 청구 출처를 숨깁니다
경로 src/providers/free-directory.ts muse-spark-web - Muse 이름만 같은 다른 참고 행입니다. muse-code/ 와 섞이면 세 번째 출처가 같은 모델처럼 보입니다
경로 src/adapters/openai-responses.ts stripMuseSparkUnsupportedWebSearchFields - Responses HTTP 본문 보정입니다. MSP session/turn/approval/userInput 번역이 아닙니다
경로 Codex Responses 계약 vs muse serve MSP - 세션 친화, 스트리밍, 도구, 승인, userInput, 취소를 한 번에 맞추려면 새 번역 층이 필요합니다. 못 맞추면 조용히 텍스트 완결로 떨어지면 안 됩니다
경로 자식 프로세스 감독 Windows/macOS/Linux - 시작·유휴·턴·취소·종료 시간이 없으면 죽은 muse 호스트가 Codex 요청을 붙잡습니다. Cursor spawn 과 Command Code execFile 은 이 세션 수명이 아닙니다
경로 Meta Muse Code 구독 약관 - 메인테이너가 건너뛰면 안 되는 확인입니다. 지원한다고 적기 전에 현재 약관과 muse serve 경계를 읽어야 합니다
경로 Muse 자격 저장소 - 토큰을 꺼내 OpenCodex에 복사하는 구현은 하지 않습니다. 로그인 안내는 공식 muse login 뿐입니다

메인테이너의 판단이 필요한 지점

• OpenCodex가 MSP 어댑터를 직접 가질지, Muse CLI는 따로 쓰라고 둘지
• 첫 조각이 코딩 세션 없는 읽기 전용 muse 실행 파일·로그인·구독 자격 조사인지
• 카탈로그 이름을 muse-code/ 로 둘지, 기존 HTTP Muse 행의 라벨 형제로 둘지
• 이 설계를 지금 버그·랜딩 열차가 끝난 뒤로 미룰지

너의 추천
지금 구현하지 마십시오. 이슈는 열어 두고 needs-design 으로 남기십시오. 이 댓글은 라벨을 바꾸지 않습니다. 언젠가 첫 조각을 한다면, 코딩 세션을 켜지 않고 자격도 복사하지 않는 읽기 전용 실행 파일·로그인·구독 자격 조사만 하십시오. HTTP Muse 경로의 중복으로 닫지 마십시오. 청구 출처가 이 이슈의 실제 요청입니다.

이 댓글은 grok-bot이 작성했습니다

Translated Message

Original language: Korean

Review · Priority 49 / 80

Description

This issue is not asking OpenCodex to let Codex choose Muse Spark. You can already choose it via HTTP. What the reporter (SOSANA) wants is a different billing behavior. The request is: install the official muse CLI, run muse login to sign into a Meta account, then when selecting a model whose path shows a subscription (e.g. muse-code/muse-spark-1.2) from Codex, that request should only decrement the Muse Code subscription quota. Leave the Meta Model API key path available, but it must not look the same in name, logs, and dashboard as the subscription path. It must not silently fall back to the API key when the subscription expires. OpenCodex must not extract and store Muse tokens.

Currently checkout HEAD is 88c4275. The title is feat(combo): adapt reasoning effort to target capabilities (#2731) (#3190). Package is 2.40.0. This train is a follow-up for combo effort ladder, capacity/quotas, and remote-hub. Spawning a muse serve child process and a new adapter family that speaks MSP is not what this train is optimizing. It's unrelated to the automatic barrel splitting for types.ts. Because this is an issue, it's not a close-don't-rebase target.

Today, OpenCodex's Muse path is the HTTP API key. The lightweight meta-model-api + openai-chat + https://api.meta.ai/v1 path is not a built-in provider stuck in the repo. It's an openai-chat path the user attached with an API key. That path sends requests and receives responses. But Meta bills that as Model API usage. Even if the same Meta account has a Muse Code subscription, API key requests do not decrement the subscription quota. As the reporter verified on 2026-09-01, only the official muse exec decremented the subscription window while the pay-as-you-go balance remained. The HTTP path working does not mean the subscription path already exists.

The Muse Spark entries already in HEAD are also HTTP. src/providers/registry.ts lists meta/muse-spark-1.2 and meta/muse-spark-1.2-contributor as Command Code image models. src/providers/command-code-efforts.ts attaches an effort ladder from low to max to that id. The OpenCode Go provider sends muse-spark-1.2-contributor to openai-responses and sets the context window to 1_048_576. src/adapters/openai-responses.ts's stripMuseSparkUnsupportedWebSearchFields selects only that contributor id and removes the web_search search_content_types field. These are all model calibrations on top of the HTTP adapter. They are not Muse Code subscription sessions.

The wiring in the adapter registry src/adapters/registry.ts is command-code, openai-chat, ollama-native, anthropic, openai-responses, google, kiro, cursor. AgentRouter(#2843) is an HTTP-compatible helper, and ollama-native(#2863) is local REST. Cursor is protobuf-over-HTTP, and Kiro wraps a completion tool over HTTP. Neither is a child-process session host. MSP, stdio providers, muse serve, muse-code, muse-msp files are not in src. Sidecars are only web-search and vision, and OpenCodex doesn't spin up external coding agents. The spawn/execFile calls inside Cursor and Command Code are for tool execution. They are not places that hold provider sessions.

Therefore this issue should not be closed as if it were the HTTP Muse row. The heart of the request is the billing source. #1213 already documented the same principle. Don't put the same model name in the catalog and then send requests under API credentials that bill separately and hide the subscription. #1213 was about Claude Desktop, but the point — don't hide a differently-billed path behind the same name — is the same here. Implementing this requires multiple pieces, not one PR: investigation of executable/login/subscription credentials, child-process lifetimes, Responses contract vs MSP session/turn/approval/userInput translation, catalog source labeling, and a security review so requests don't quietly fall back to API keys. Putting this onto the current bug/landing train enlarges the scope. Score 49. The billing-source hole is real, but this is a new adapter family and current HEAD didn't put this work in the next car.

Paths referenced:

• src/adapters/registry.ts ADAPTER_REGISTRY - there is no slot for MSP·stdio·muse-msp. There is no existing adapter to attach this issue to
• src/providers/registry.ts meta/muse-spark-1.2 · meta/muse-spark-1.2-contributor · OpenCode Go muse-spark-1.2-contributor - already HTTP Muse Spark rows. Raising a subscription path under the same id would hide the billing source in the catalog
• src/providers/free-directory.ts muse-spark-web - another reference row that only shares the Muse name. Mixing with muse-code/ would look like a third source that appears to be the same model
• src/adapters/openai-responses.ts stripMuseSparkUnsupportedWebSearchFields - Responses HTTP body calibrations. Not MSP session/turn/approval/userInput translation
• Codex Responses contract vs muse serve MSP - to align session-friendly streaming, tools, approvals, userInput, and cancellation at once requires a new translation layer. If not matched, it must not silently drop to plain text completions
• Child process supervision Windows/macOS/Linux - without start/idle/turn/cancel/exit times, a dead muse host can hold Codex requests. Cursor spawn and Command Code execFile are not session lifetimes for this
• Meta Muse Code subscription terms - maintainers must not skip the verification. Read current terms and muse serve boundaries before claiming support
• Muse credential storage - do not implement extracting tokens into OpenCodex. Login guidance should be the official muse login only

Points where maintainer judgment is needed

• Whether OpenCodex should directly host an MSP adapter or leave the Muse CLI to be used separately
• Whether the first piece should be a read-only muse executable/login/subscription credential investigation without turning on coding sessions
• Whether to name the catalog path muse-code/ or sibling-label it to the existing HTTP Muse rows
• Whether to defer this design until after the current bug/landing train

Your recommendation
Do not implement this now. Leave the issue open and mark it needs-design. This comment does not change labels. If a first piece is done someday, make it a read-only executable/login/subscription credential investigation that does not enable coding sessions and does not copy credentials. Do not close due to duplication with the HTTP Muse path. The billing source is the real request here.

This comment was written by grok-bot

[SOSANA]

Thanks for the careful review. This captures the distinction I wanted to establish: the existing HTTP Muse rows work, but they are separately billed API routes and should not be treated as Muse Code subscription access.

I agree this should not expand the current landing train. Leaving the issue open as needs-design makes sense.

My preference on the open points is:

• If OpenCodex eventually supports Muse as a selectable primary route, it should be an explicit process-backed adapter boundary; until then, Muse CLI should remain separate.
• The first slice should only be a read-only feasibility probe: executable/version detection, official login state, model/schema discovery, and whether subscription eligibility can be established without copying credentials or starting coding sessions.
• A future subscription route should use a provenance-bearing namespace such as muse-code/, distinct from meta-model-api/.
• Deferring implementation until after the current train is fine.

I am happy to contribute additional protocol or observed-behavior evidence if it helps that design pass, but I am not proposing that the full adapter be scheduled now.

[agentHits]

Good idea ! Thanks you!