Repository navigation
Support OpenScience (@synsci/openscience) as a client integration #4854
Description
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?
- Detect OpenScience installations or local configuration directory and support automatic proxy injection (or an explicit command such as
ocx inject openscience). - Expose routed models in OpenScience's provider/model selector.
- Include OpenScience in
ocx doctorchecks.
Example usage or interface
ocx start
# OpenCodex detects OpenScience and injects local proxy config:
# [opencodex] OpenScience configured -> http://127.0.0.1:10100/v1
openscienceAlternatives 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.
Activity
lidge-jun commentedon Sep 17, 2026
리뷰 · 우선순위 48 / 80
이 이슈는 OpenScience(
@synsci/openscience, OpenCode 계열 과학 연구 워크벤치)를 Codex·Claude Code·Claude Desktop처럼 OpenCodex가 자동으로 감지·주입해 주길 바라는 클라이언트 통합 요청입니다. 지금은openscience local add로http://127.0.0.1:10100/v1OpenAI 호환 엔드포인트를 수동으로 넣는 우회가 이미 동작합니다. 원하는 것은 (1) 설치/설정 디렉터리 감지 후ocx start또는ocx inject openscience식 자동 주입, (2) 라우트된 모델을 OpenScience 선택기에 노출, (3)ocx doctor점검 포함입니다.지금
devHEAD7ef3f6745의 클라이언트 쪽 현실은 이미 “파일 기반 통합 레지스트리”로 정리되어 있습니다.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와 아키가 닮았다면opencodeexport(opencode.jsonV1/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가 없고, 가장 가까운 템플릿은opencodeexport다. 스키마가 다르면 새 모듈이 필요하다.경로
src/integrations/registry.ts- enable/disable·저널 대상 클라이언트 목록에 openscience가 없다.경로
src/cli/doctor.ts- OpenScience 설치/주입 상태 점검이 없다.심볼
@synsci/openscience-dev트리에 참조가 없어, 설정 파일 경로·프로바이더 블록 키가 이 이슈만으로는 확정되지 않는다.경로 우선순위 - 수동
openscience local add우회가 있으므로, 자동 주입은 “편의” 티어지 “막힘” 티어가 아니다.메인테이너의 판단이 필요한 지점
integration client로 받을지, 문서에 OpenAI-compat 수동 연결만 안내할지ocx integration client enable --client openscience만으로 시작할지너의 추천
닫지 말고 enhancement로 두되, 지금 바로 구현 큐 앞에는 올리지 않는 쪽을 추천한다. 다음 액션은 기여자에게 OpenScience 설정 파일 경로·프로바이더 JSON 스키마 샘플(비밀 제거)을 받아
opencodeexport와 diff한 뒤, 같으면 얇은 client id 추가 / 다르면 별도 export 모듈 설계로 이슈를 쪼개면 된다. 수동 우회가 되는 한 merge-blocking은 아니다.이 댓글은 grok-bot이 작성했습니다
lidge-jun commentedon Sep 27, 2026
Release train 4 triage: please keep this issue open. The manual OpenAI-compatible endpoint already provides a usable path. Before automatic OpenScience injection, we need its documented configuration path and provider schema, plus a precise ownership and compare-before-restore contract for the entries OpenCodex would write. A secret-free example from the supported OpenScience configuration surface would make the next implementation proposal reviewable.
lidge-jun commentedon Oct 9, 2026
Closing as stale: evidence was requested on 2026-09-27 with no reply since. Happy to reopen if you can share the requested evidence on a current build.