Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
52 lines (37 loc) · 2.31 KB

CONTRIBUTING.md

File metadata and controls

52 lines (37 loc) · 2.31 KB
Raw

Contributing to Mcode

Mcode combines Code-OSS with the open-source Codex app-server runtime. Keep the product boundary intact: Code-OSS owns the IDE shell, Codex owns agent execution, and Mcode owns the thin integration and user experience.

Development setup

Prerequisites for the protocol and Workbench packages:

  • Node.js 24.19 or compatible Node 24;
  • pnpm 10.15;
  • Git.
pnpm install --frozen-lockfile
pnpm test
pnpm typecheck
pnpm check:webview
pnpm --filter mcode-workbench build

Official VS Code can run the packaged extension from vendor/code-oss/extensions/mcode-workbench for right-sidebar development. Cursor reserves its secondary sidebar; source-extension development there uses the primary-sidebar fallback.

Full Code-OSS Windows builds additionally require Visual Studio 2022 C++ tools and matching Spectre-mitigated libraries. See docs/RELEASE.md.

Generated and prepared inputs

  • Do not hand-edit packages/codex-protocol/src/generated.
  • Do not commit vendor/code-oss, .engine-build, downloaded VSIX files, compiled Codex binaries, tokens, logs, or user data.
  • Update the Codex runtime manifest and generated protocol bindings atomically.
  • Verify every downloaded binary or VSIX against the committed size and SHA-256.
  • Add a license copy and third-party notice before introducing a curated built-in component.

Architecture rules

  • Do not implement a second agent loop, MCP client, patch executor, sandbox, or thread database.
  • Add stable app-server methods to CodexProvider, then normalize only the product concepts the UI needs.
  • Keep tokens and secrets out of renderer messages, settings, logs, command lines, tests, and fixtures.
  • Keep proposal review non-destructive; never implement Reject using Git reset/checkout or whole-file overwrite.
  • Constrain file navigation and context references to open workspace roots.
  • Preserve unrelated user work and keep generated artifacts outside Git.

Pull requests

Every change should include:

  • a focused description of the product behavior;
  • tests proportional to protocol, filesystem, permission, or packaging risk;
  • updated documentation and smoke records when behavior changes;
  • the exact commands used for verification;
  • no unreviewed binary or license changes.

Run node scripts/release/preflight.mjs before requesting review.