Support OpenScience (`@synsci/openscience`) as a client integration

[jmzhang1911]

Area

Multiple areas

What are you trying to accomplish?

I want to use OpenScience (synthetic-sciences/openscience, npm: @synsci/openscience) with models routed through OpenCodex (Gemini, Claude, DeepSeek, Kimi, GLM, etc.), with automatic configuration similar to how OpenCodex currently supports Codex, Claude Code, and Claude Desktop.

What prevents this today?

Currently, ocx start and auto-injection support Codex, Claude Code, and Claude Desktop. To use OpenCodex with OpenScience, users must manually configure an OpenAI-compatible custom provider endpoint via openscience local add pointing to http://127.0.0.1:10100/v1.

What should OpenCodex do?

1. Detect OpenScience installations or local configuration directory and support automatic proxy injection (or an explicit command such as ocx inject openscience).
2. Expose routed models in OpenScience's provider/model selector.
3. Include OpenScience in ocx doctor checks.

Example usage or interface

ocx start
# OpenCodex detects OpenScience and injects local proxy config:
# [opencodex] OpenScience configured -> http://127.0.0.1:10100/v1

openscience

Alternatives or workarounds

Manually adding a local OpenAI-compatible provider in OpenScience pointing to http://127.0.0.1:10100/v1.

Additional context

• OpenScience repository: https://github.com/synthetic-sciences/openscience
• OpenScience package: https://www.npmjs.com/package/@synsci/openscience
• OpenScience is an open-source AI workbench for scientific research based on the OpenCode architecture.

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.

[lidge-jun]

리뷰 · 우선순위 48 / 80

이 이슈는 OpenScience(@synsci/openscience, OpenCode 계열 과학 연구 워크벤치)를 Codex·Claude Code·Claude Desktop처럼 OpenCodex가 자동으로 감지·주입해 주길 바라는 클라이언트 통합 요청입니다. 지금은 openscience local add로 http://127.0.0.1:10100/v1 OpenAI 호환 엔드포인트를 수동으로 넣는 우회가 이미 동작합니다. 원하는 것은 (1) 설치/설정 디렉터리 감지 후 ocx start 또는 ocx inject openscience식 자동 주입, (2) 라우트된 모델을 OpenScience 선택기에 노출, (3) ocx doctor 점검 포함입니다.

지금 dev HEAD 7ef3f6745의 클라이언트 쪽 현실은 이미 “파일 기반 통합 레지스트리”로 정리되어 있습니다. ocx integration client <enable|disable|…> --client <id>가 있고, export/통합 ID는 opencode, mcode, zcode, aside, cline 등입니다(src/clients/config-export.ts의 EXPORT_CLIENTS, src/integrations/registry.ts). OpenScience / @synsci/openscience / synsci 문자열은 트리에 없습니다. OpenCode와 아키가 닮았다면 opencode export(opencode.json V1/V2 블록, src/clients/config-export.ts)를 참고해 새 client id를 추가하는 패턴이 가장 가깝습니다. 다만 OpenScience의 실제 설정 경로·스키마·프로바이더 키 이름이 opencode와 동일한지는 이 이슈만으로는 검증되지 않았고, npm/깃허브 링크만 있습니다. Claude Desktop(ocx claude desktop)이나 Codex inject(src/codex/inject/)처럼 클라이언트가 다르면 경로·저널·롤백 계약이 통째로 달라집니다.

우선순위가 중간 이하인 이유는 명확합니다. 수동 OpenAI-compat 우회가 이미 있고, 새 클라이언트 통합은 감지·쓰기·doctor·저널·충돌·복원까지 한 세트가 필요합니다. 지금 dev가 최적화하는 축은 Windows 게이트 여유(#4851 계열), 행동 계약 테스트(#4846), kill/reap(#4849), 프로바이더 호환 핫픽스(#4852·#4853 같은 즉시 깨짐) 쪽에 가깝습니다. OpenScience는 “있으면 좋은 클라이언트 표면”이지, 프록시 코어가 막힌 상태는 아닙니다. types.ts/config.ts 대형 분리와도 직접 충돌하지는 않지만, 새 export client를 넣으면 EXPORT_CLIENT_IDS·통합 레지스트리·doctor 체크·문서가 한 묶음으로 늘어납니다.

경로 src/clients/config-export.ts / EXPORT_CLIENTS - OpenScience id가 없고, 가장 가까운 템플릿은 opencode export다. 스키마가 다르면 새 모듈이 필요하다.
경로 src/integrations/registry.ts - enable/disable·저널 대상 클라이언트 목록에 openscience가 없다.
경로 src/cli/doctor.ts - OpenScience 설치/주입 상태 점검이 없다.
심볼 @synsci/openscience - dev 트리에 참조가 없어, 설정 파일 경로·프로바이더 블록 키가 이 이슈만으로는 확정되지 않는다.
경로 우선순위 - 수동 openscience local add 우회가 있으므로, 자동 주입은 “편의” 티어지 “막힘” 티어가 아니다.

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

• OpenScience를 1급 integration client로 받을지, 문서에 OpenAI-compat 수동 연결만 안내할지
• OpenCode export를 재사용할 수 있을 만큼 설정 호환인지(기여자에게 opencode.json vs openscience 설정 diff 요청)
• doctor/start 자동 감지까지 포함할지, 일단 ocx integration client enable --client openscience만으로 시작할지

너의 추천
닫지 말고 enhancement로 두되, 지금 바로 구현 큐 앞에는 올리지 않는 쪽을 추천한다. 다음 액션은 기여자에게 OpenScience 설정 파일 경로·프로바이더 JSON 스키마 샘플(비밀 제거)을 받아 opencode export와 diff한 뒤, 같으면 얇은 client id 추가 / 다르면 별도 export 모듈 설계로 이슈를 쪼개면 된다. 수동 우회가 되는 한 merge-blocking은 아니다.

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