TypeScript SDK

• Automate fixes, reviews, or code generation in CI/CD;
• Embed MiniMax Code in internal tools or your own agents;
• Orchestrate multi-turn Sessions from code instead of hand-written mcode exec pipelines.

​

Requirements

​

Installation

npm install @minimax-ai/code-sdk
npm install @minimax-ai/code   # optional; a globally installed mcode works too

{
  "allowScripts": {
    "@minimax-ai/code": true,
    "better-sqlite3": true
  }
}

​

Quick start

import { MCode } from "@minimax-ai/code-sdk";

const mcode = new MCode({ dataDir: "/srv/mcode-data" });
const thread = mcode.startThread({
  cwd: "/path/to/repo",
  model: "minimax/MiniMax-M3",
  permission: "smart",
});

const turn = await thread.run("Diagnose and fix the failing CI job", {
  files: ["./ci.log"],
  timeoutMs: 10 * 60_000,
});
console.log(thread.id, turn.finalResponse, turn.usage);

// Continue on the same Thread
await thread.run("Add unit tests for the fix");

// Resume an earlier Session
const resumed = mcode.resumeThread("mvs_xxx", { cwd: "/path/to/repo" });
await resumed.run("Continue where you left off");

const { events } = await thread.runStreamed("Implement the plan");
for await (const event of events) {
  switch (event.type) {
    case "item.completed":
      console.log(event.item);
      break;
    case "turn.failed":
      console.error(event.status, event.error);
      break;
    default:
      // Newer CLIs may add event types; the SDK passes them through unchanged.
      break;
  }
}

​

CLI resolution

1. The bin constructor option (executable, JS entry, or command name on PATH);
2. An installed @minimax-ai/code next to the SDK (optional peer);
3. mcode on PATH.

​

new MCode(options?)

const mcode = new MCode({ env: { ...process.env, FOO: "bar" } });

​

Threads: startThread / resumeThread

• mode: "lightweight" is only valid for a new Thread; passing it to resumeThread throws MCodeInvocationError immediately;
• There is no ask permission for headless runs. MiniMax Code’s smart / full / off policies are not equivalent to Codex OS sandbox modes, and the SDK does not map between them;
• thread.id becomes available once the first Turn emits its first event, even if that Turn fails.

​

thread.run / thread.runStreamed

• run() resolves only when the status is succeeded, with a Turn (finalResponse, normalized items, usage, model, sessionId, turnId, durationMs, and the full result). Every other outcome rejects;
• runStreamed() yields CLI events unchanged. turn.failed is an ordinary event; the iterator throws only for process or protocol failures. Breaking out of the loop cancels the Turn;
• A Thread runs one Turn at a time. A concurrent call throws ThreadBusyError; Turns are not queued.

​

Events and items

​

Errors

​

Cancellation and timeouts

• When signal aborts, the SDK sends SIGTERM. The CLI cancels and shuts down (up to about 60 seconds); after that budget the SDK sends SIGKILL;
• timeoutMs is enforced by the CLI after access checks, session resolution, and model selection. The SDK starts its timer at spawn and force-stops at timeoutMs + 90s;
• On a normal host exit, the SDK sends SIGTERM to any running CLI and deletes temporary system-prompt directories. A host killed by a signal does not emit exit, so child processes may remain. Phase 1 has no close() / dispose();
• On Windows, Node.js cannot deliver a catchable signal to a child process, so SIGTERM is a hard kill.

const controller = new AbortController();
process.once("SIGTERM", () => controller.abort());
await thread
  .run(prompt, { signal: controller.signal })
  .catch(() => undefined);

​

Not available in Phase 1

• outputSchema (structured-output constraints);
• Approval callbacks, steering a running Turn, continuing after an interrupt, and forking.