Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Closed
#4,854 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
52/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
node.js, typescript
Domain
cli, tooling

Research direction

Start by reading the existing ocx start auto-injection paths for Codex, Claude Code, and Claude Desktop, along with the ocx doctor checks. Then investigate how OpenScience stores local configuration and exposes providers and models. Done means OpenCodex can configure OpenScience to use the local proxy, show routed models, and include it in doctor checks.

Written by the indexing model from the issue text.

Description

enhancement priority: P3 provider
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
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.
Dominant language
TypeScript
Stars
16.9k
Forks
1.3k
Avg merge
7h 34m
Merged PRs (30d)
667

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from lidge-jun/opencodex

All issues in lidge-jun/opencodex

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.