omp-worker-mcp

io.github.divenire990由 GitHub 账号 divenire990 发布v0.2.1更新于 Oct 25, 2026

Hand off coding tasks from ChatGPT, Codex or Claude Code to local Oh My Pi (OMP) workers.

已验证STDIO仅桌面开发者工具AI 与机器学习

概览

AI 生成的概览

把 MCP 客户端接到本机 Oh My Pi(OMP)工作进程,让助手把编码任务委派给后台代理并审阅精简结果。

可以做什么
  • 把单个编码任务委派给本机 OMP 工作进程,返回精简摘要、产物与验证证据
  • 以依赖图方式批量运行最多 50 个任务,最多 10 个并行,并需声明写入范围
  • 等待运行中的任务或任务组,必要时获取完整尝试日志与最终回复
  • 向同一 OMP 会话发送纠正反馈,或取消单个任务、整个任务组及其进程树
适用场景
适合让主模型负责规划与验收、由本机另一个 OMP 代理实际改代码、跑命令和测试的场景,例如新功能、带测试的缺陷修复、重构或仓库内并行工作。单行改动或快速提问则不值得使用。
运行要求
通过 npx 以 stdio 在本机运行,需要 Node.js 22 或更高版本,并已安装和配置 Oh My Pi(omp setup 选择默认模型)。需用 OMP_WORKER_OMP_COMMAND 指向 OMP 可执行文件;OMP_WORKER_ALLOWED_ROOTS 可选,用于限制任务目录。经隧道远程使用时还需隧道客户端及其 API 密钥。
安装前请注意
它不是沙箱:OMP 及其运行的任何内容都拥有启动服务器的用户账户权限,写入范围只是调度检查而非文件系统锁。工作进程会修改文件并执行 shell 命令,git push、发布、部署和密钥变更应保留给人工确认。任何远程暴露都应设置 OMP_WORKER_ALLOWED_ROOTS,并注意 npm 0.1.1 版本没有该白名单。

安装

在 SourceWeft 中

  1. 打开 控制台中的 omp-worker-mcp,将其添加到工作区。
  2. 为需要使用其工具的对话启用该服务。

Desktop only,通过 STDIO。 STDIO 服务会启动本地进程,因此需要 SourceWeft 桌面宿主。

其他 MCP 客户端

参照 仓库 中的启动说明。

README

omp-worker-mcp

Let your main AI agent plan and review — and hand the hands-on coding to local Oh My Pi workers.

An MCP server that turns ChatGPT, Codex, Claude Code, Cursor and other MCP clients into a supervisor,
and Oh My Pi (OMP) on your own machine into its background workforce.

[npm version] [CI] [Node.js] [MCP Registry] [MIT License]

English · 简体中文 · Documentation


[The supervisor agent delegates tasks to omp-worker-mcp, which runs OMP workers in the background and returns structured results for review]

Quick start · Usage · Tools · Configuration · Safety model · FAQ


What it does

Most coding agents do everything in one place: read the code, plan, edit, run tests, fix — all inside one conversation and one model's budget. omp-worker-mcp splits that work into two roles:

RoleWhoResponsibility
SupervisorThe agent you talk to: ChatGPT, Codex, Claude Code, Cursor…Understands the request, splits the work, writes acceptance criteria, reviews the results
WorkerThe OMP CLI on your machine, using the model you picked in omp setupReads files, edits code, runs shell commands and tests, reports back

omp-worker-mcp is the bridge between them. It gives the supervisor a small set of MCP tools, starts OMP in the background, keeps every job on disk, and returns a short structured report instead of a wall of logs.

Highlights

  • One task or a whole plan — omp_run_compact delegates a single task; omp_run_batch_compact runs up to 50 tasks as a dependency graph (DAG), up to 10 at a time.
  • Declared write-scope validation — parallel write tasks in a batch must declare the paths they own; overlapping declared scopes and dependency cycles are rejected before any worker starts (a scheduling check and prompt constraint, not an OS filesystem lock).
  • Results you can review — every worker finishes with an OMP_WORKER_RESULT envelope: status, summary, changed files, verification evidence and remaining items.
  • Correct instead of restart — omp_continue sends feedback to the same OMP session, so the worker keeps its context.
  • Persistent jobs — job records, logs and results live on disk and can still be read after the MCP server restarts.
  • Works from ChatGPT on the web — through OpenAI's Secure MCP Tunnel: no inbound port, plus an allowlist (OMP_WORKER_ALLOWED_ROOTS, available since 0.2.0; npm 0.1.1 lacks this feature) for the directories jobs may run in.

When to use it

A good fit when

  • you want a strong model to make the decisions while a faster or cheaper model does the typing;
  • the task is big enough to hand off: a feature, a bug fix with tests, a multi-module refactor, a long read-only investigation;
  • you want several parts of a repo worked on in parallel without agents overwriting each other;
  • you think with ChatGPT and want it to act on files on your own machine.

Probably not worth it when

  • the change is one line or the question is quick — the supervisor's own tools are faster;
  • you need a real OS-level sandbox. This project controls where jobs start and what they are told to touch, not what OMP is technically able to do (see Safety model).

Quick start

You need: Node.js ≥ 22 · Oh My Pi installed · an MCP client (Codex, Claude Code, Cursor, ChatGPT, …).

1. Install and set up OMP

Install OMP by following its official instructions, then:

bash
omp --version   # confirm the CLI is on your PATHomp setup       # sign in and choose the default model

The default model you pick here is the model every worker will use. (Advanced: set modelRoles.default: <provider>/<model> in ~/.omp/agent/config.yml.)

If omp is not on your PATH, set OMP_WORKER_OMP_COMMAND to the full path of the executable in the MCP config below.

2. Register the MCP server in your client

There is nothing to install globally — the client runs the published package with npx -y omp-worker-mcp. Pick your client:

Codex — the author's daily setup

Edit ~/.codex/config.toml (Windows: C:\Users\<you>\.codex\config.toml):

toml
[mcp_servers.omp-worker]command = "npx"args = ["-y", "omp-worker-mcp"]
[mcp_servers.omp-worker.env]OMP_WORKER_OMP_COMMAND = "omp"
# Optional (Codex Code Mode only): let Codex call omp-worker tools directly# without code-mode wrapping. Per the current Codex config reference, merge into# your existing [features.code_mode] table (do not create a duplicate table header)# and append "mcp__omp_worker" while preserving any other list entries:[features.code_mode]direct_only_tool_namespaces = ["mcp__omp_worker"]

(If [features.code_mode] already exists in your config.toml, merge into that table and append "mcp__omp_worker" to direct_only_tool_namespaces rather than duplicating the table or overwriting existing entries. Legacy Codex builds used a top-level direct_only_tool_namespaces = ["mcp__omp_worker"] key before any [table] header. Neither setting is required to register the MCP server; see Codex direct namespace setup and the official Codex Config Reference.)

ChatGPT (web) — via Secure MCP Tunnel

Version requirement (>= 0.2.0): OMP_WORKER_ALLOWED_ROOTS is available since omp-worker-mcp 0.2.0 (historical npm 0.1.1 lacks this feature and does not enforce OMP_WORKER_ALLOWED_ROOTS). Confirm npx -y omp-worker-mcp@latest --version reports 0.2.0 or newer before exposing local execution remotely.

Run the server locally behind OpenAI's tunnel-client; your machine only makes outbound connections.

bash
export OMP_WORKER_OMP_COMMAND=ompexport OMP_WORKER_ALLOWED_ROOTS='["/Users/you/Projects"]'   # strongly recommended for remote access (available since 0.2.0; 0.1.1 lacks this feature)export CONTROL_PLANE_API_KEY='<runtime-api-key>'
tunnel-client init \  --sample sample_mcp_stdio_local \  --profile omp-worker \  --tunnel-id <your-tunnel-id> \  --mcp-command "npx -y omp-worker-mcp"
tunnel-client doctor --profile omp-worker --explaintunnel-client run --profile omp-worker

Windows PowerShell commands, 0.1.1 upgrade / local-build notes, managed runtime alternatives (tunnel-client runtimes connect), permission requirements and the full trust boundary: ChatGPT Secure MCP Tunnel guide.

Claude Code
bash
claude mcp add omp-worker --scope user --env OMP_WORKER_OMP_COMMAND=omp -- npx -y omp-worker-mcp

Use --scope project to register it for the current project only. On Windows cmd.exe, if npx fails to resolve, use cmd /c npx.

Cursor · VS Code / Copilot · Windsurf · Continue · any JSON-config client
json
{  "mcpServers": {    "omp-worker": {      "command": "npx",      "args": ["-y", "omp-worker-mcp"],      "env": {        "OMP_WORKER_OMP_COMMAND": "omp"      }    }  }}

File locations and client-specific notes: Client configurations.

Restart the client after changing its config.

3. Tell your agent when to delegate

Registering the server makes the tools available; it does not make the agent choose them. Add a short policy to your project's instruction file — AGENTS.md (Codex), CLAUDE.md (Claude Code), .cursorrules / .github/copilot-instructions.md (others) — or to ChatGPT's project instructions:

markdown
## Delegation policy (omp-worker-mcp)- Quick questions, single-file edits, design discussion: do it yourself.- Substantive single tasks (feature, bug fix, refactor, long investigation): inspect briefly,  then delegate with `omp_run_compact`, giving a clear `goal` and `acceptance` criteria.- Multi-part work: use `omp_run_batch_compact`. Parallel write tasks need disjoint `ownership`;  tasks touching the same files must be ordered with `depends_on`.- Review every result. If acceptance is not met, use `omp_continue` with specific feedback.- Never delegate `git push`, publishing, deployments or secret changes — confirm those with the user.

A fuller template: Author workflow → Policy template.

4. Run your first task

Start with something read-only:

text
Use omp-worker-mcp to do a read-only inspection of this workspace: summarize theproject structure and dependencies. Do not modify any files.

What you should see: the agent calls omp_run_compact, OMP works in the background, and a short summary comes back with no files changed. If the job runs longer than the wait window (60 s by default), the call returns a job_id with status running and the agent keeps going with omp_wait — that is normal.


Usage

Once the policy is in place you can just describe the outcome you want. The examples below show what the supervisor sends under the hood.

A single task

"Add exponential backoff to the HTTP client in src/net/, cover it with unit tests, and make sure npm test passes."

jsonc
// omp_run_compact{  "cwd": "/path/to/repo",  "goal": "Add exponential backoff (max 5 retries) to src/net/client.ts for 5xx and network errors.",  "acceptance": [    "Unit tests cover the retry and give-up paths",    "npm test passes"  ],  "timeout_minutes": 30}

What comes back is compact (abridged example):

jsonc
{  "job_id": "job-…",  "status": "completed",  "attempt": 1,  "max_attempts": 3,  "session_id": "sess-…",  "summary": "Added retry with exponential backoff to the HTTP client.",  "artifacts": [    { "path": "src/net/client.ts", "description": "retry loop + backoff helper" },    { "path": "test/net/client.test.ts", "description": "retry / give-up tests" }  ],  "verification": ["npm test: all tests passed"],  "remaining": [],  "details_path": "…/jobs/job-…/job.json"}

Several tasks as a DAG

"Add a /health endpoint to the API and a status badge to the UI in parallel, then add an integration test that covers both."

mermaid
graph LR  api["api · write src/api/"] --> tests["tests · write tests/"]  ui["ui · write src/ui/"] --> tests
jsonc
// omp_run_batch_compact{  "cwd": "/path/to/repo",  "max_parallel": 2,  "tasks": [    { "id": "api",   "goal": "Add GET /health returning build info.", "access": "write", "ownership": ["src/api/"] },    { "id": "ui",    "goal": "Show a status badge fed by /health.",   "access": "write", "ownership": ["src/ui/"] },    { "id": "tests", "goal": "Add an integration test for /health and the badge.",      "depends_on": ["api", "ui"], "access": "write", "ownership": ["tests/"],      "acceptance": ["npm test passes"] }  ]}

Rules worth knowing:

  • write tasks must list the paths they own in ownership (relative to cwd); read_only tasks list none.
  • Two tasks that may run at the same time cannot own overlapping paths — order them with depends_on instead.
  • max_parallel is 1–10 (default 4); the whole group has a deadline (group_timeout_minutes, default 60).
  • If the group is still running when the wait window ends, you get a group_id; continue with omp_wait_group.

Supervising a job

SituationTool
Still runningomp_wait / omp_wait_group
Need logs, attempts or the full final answeromp_result
Result doesn't meet acceptanceomp_continue with concrete feedback (counts toward max_attempts, default 3)
Wrong direction, stop itomp_cancel / omp_cancel_group

Tools

ToolKindWhat it does
omp_run_compactRecommendedStart one task and wait up to wait_seconds (≤ 60) for a compact result
omp_run_batch_compactRecommendedValidate and run a DAG of up to 50 tasks; wait up to wait_seconds (≤ 240)
omp_delegateLow-levelStart one task and return a job_id immediately
omp_waitLow-levelWait for a job to finish
omp_wait_groupLow-levelWait for a batch group to finish
omp_resultInspectFull status, attempts, attempt-NN.stdout.jsonl / attempt-NN.stderr.log paths, final response
omp_continueSuperviseSend feedback to the same OMP session for another attempt
omp_cancelControlStop a job and its process tree
omp_cancel_groupControlStop every pending and running task in a group

Full parameters and limits: Tool reference.


Configuration

Everything is configured through environment variables, set in the client's MCP config (env) or in the shell that launches the server.

VariableDefaultPurpose
OMP_WORKER_OMP_COMMANDompOMP executable name or full path
OMP_WORKER_ALLOWED_ROOTS(unset = no restriction)JSON array of absolute directories that jobs must run inside. Set this for any remote use. (Available since 0.2.0; npm 0.1.1 lacks this feature.)
OMP_WORKER_STATE_DIR~/.codex/state/omp-workerWhere job state, prompts and logs are stored (the default path is used even if you don't use Codex)
OMP_WORKER_RETENTION_TTL_SECONDS(unset = keep forever)Delete finished records older than N seconds
OMP_WORKER_RETENTION_MAX_BYTES(unset = no limit)Delete the oldest finished records once the store exceeds N bytes

All variables, the on-disk layout and restart behaviour: Operations · .env.example.


Safety model

What omp-worker-mcp enforces

  • With OMP_WORKER_ALLOWED_ROOTS set (available since 0.2.0; npm 0.1.1 lacks this feature), a job's cwd must resolve (via realpath) inside an approved root. Sibling-prefix tricks and symlink/junction escapes are rejected before OMP starts; a present-but-invalid value fails closed.
  • In a batch, parallel write tasks must have disjoint ownership, and the graph must be acyclic — checked before any worker is spawned.
  • Ownership and read-only intent are passed to each worker as explicit constraints.

What it does not do

  • It is not a sandbox. OMP and anything it runs have the same permissions as the user account that started the server. Ownership is a scheduling check plus an instruction to the worker, not a filesystem lock.
  • It does not decide what is safe to run. Keep git push, publishing, deployments and secret changes with you and the supervisor.

For remote access (e.g. ChatGPT via Secure MCP Tunnel), always set OMP_WORKER_ALLOWED_ROOTS, and consider a dedicated low-privilege account, a container or a VM. To report a vulnerability, see SECURITY.md.


Platform support

PlatformStatus
Windows✅ Verified end-to-end with the real OMP CLI and in CI (windows-latest)
macOS🟡 Full test suite runs in CI (macos-latest, with a fake OMP); not yet verified end-to-end with the real OMP CLI
Linux🟡 Full test suite runs in CI (ubuntu-latest, with a fake OMP); not yet verified end-to-end with the real OMP CLI
ClientStatus
Codex✅ Used daily by the author
ChatGPT web (Secure MCP Tunnel)📄 Documented workflow — see the guide
Claude Code, Cursor, VS Code / Copilot, Windsurf, Continue📄 Documented configurations, not integration-tested in CI
Cloud / remote agent hosts⚠️ Only if they provide Node.js ≥ 22, OMP on PATH, a writable workspace and process spawning

Linux reports and client configs that you have verified are very welcome — see Contributing.


FAQ

The agent ignores the tools and does everything itself.

Tools being available doesn't mean they get chosen. Add the delegation policy from step 3, or name the server explicitly in your prompt ("use omp-worker-mcp to…"). On Codex with Code Mode enabled, you can also optionally configure features.code_mode.direct_only_tool_namespaces.

The job fails right away with "command not found" / ENOENT.

The MCP server can't find OMP. Set OMP_WORKER_OMP_COMMAND to the full path of the executable — GUI clients often start with a shorter PATH than your terminal.

I got a job_id with status running instead of a result.

Expected for longer tasks: the call only waits up to wait_seconds. The job keeps running in the background; call omp_wait (or omp_wait_group) to keep waiting.

Which model do the workers use?

OMP's default model — the one chosen in omp setup (or modelRoles.default in ~/.omp/agent/config.yml). The supervisor's model is whatever your client uses. That's the point: they can be different.

"outside OMP_WORKER_ALLOWED_ROOTS" error.

The task's cwd is not inside any approved root. This is the allowlist working; add the directory to OMP_WORKER_ALLOWED_ROOTS if it should be allowed (note: OMP_WORKER_ALLOWED_ROOTS is available since 0.2.0; npm 0.1.1 lacks this feature).

"Concurrent write ownership conflict" error.

Two tasks that could run at the same time own overlapping paths. Give them separate ownership scopes, or add depends_on so one runs after the other.

How is this different from the subagents built into my client?

The worker is a separate agent (OMP) with its own model and provider, runs in the background across conversation turns, keeps its state on disk, and can be driven by any MCP client — including ChatGPT on the web. Batches add dependency ordering and write-scope checks on top.


Documentation

GuideRead it when you want to…
Author workflowSet up the delegation policy and understand the supervise → review → correct loop
Client configurationsConfigure Codex, Claude Code, Cursor, VS Code, Windsurf or Continue
ChatGPT Secure MCP TunnelDrive local OMP from ChatGPT on the web
Tool referenceSee every tool, parameter and the result envelope
OperationsTune environment variables, storage, retention and restarts
Benchmark protocolCompare direct execution with supervisor–worker delegation
Registry publishingRelease to npm and the Official MCP Registry (maintainers)

COMPATIBILITY.md defines the public contract and versioning policy; CHANGELOG.md lists releases.

Contributing

Issues and pull requests are welcome — especially Linux verification and tested client configs. Start with CONTRIBUTING.md. To build from source:

bash
git clone https://github.com/divenire990/omp-worker-mcp.gitcd omp-worker-mcpnpm cinpm test        # builds, then runs the test suite against a fake OMP

Acknowledgements

Built on the Model Context Protocol TypeScript SDK and designed around Oh My Pi (MIT). OMP is not bundled and must be installed separately. This project is independent and not affiliated with OMP, OpenAI or Anthropic.

License

MIT

来源:README.md,提交 700766c

工具

9

omp_run_batch_compact

Run Batch OMP Tasks with DAG and Compact Aggregated Result (Preferred for Multi-task)

Submits a decomposed group of OMP tasks to execute concurrently in the server-side bounded rolling pool (max_parallel 1-10) using a detached group runner. Enforces dependency DAG and write-ownership safety, waits up to wait_seconds (0-240, default 60s) for batch completion, and returns stable compact aggregated results. If still running when deadline elapses, returns group_id and minimal progress counts for subsequent omp_wait_group.

输入参数cwd必填tasks必填max_parallelwait_secondssupervisor_briefdefault_max_attemptsgroup_timeout_minutesdefault_timeout_minutes

omp_wait_group

Wait for Batch Task Group

Wait for an existing OMP task group to reach a terminal status, polling up to wait_seconds (0-240, default 60s). If completed, returns full aggregated compact results in original input order. If still running when deadline elapses, returns minimal progress counts without leaking task summaries.

输入参数group_id必填wait_seconds

omp_cancel_group

Cancel Batch Task Group

Request immediate cancellation of a running batch task group and its child tasks. Writes a cancellation request that the detached group coordinator handles safely. Call this immediately when the user asks to stop a batch.

输入参数reasongroup_id必填

omp_run_compact

Run OMP Task with Compact Result (Preferred for Single Task)

Preferred entrypoint for single substantive execution tasks. Creates a delegated OMP task, launches the detached runner, and waits up to wait_seconds (default 60s) for completion in a single MCP call. If finished, returns a compact summary, artifacts, verification, and details_path without dumping the full final response. If still running at the deadline, returns job_id and status running for subsequent omp_wait.

输入参数cwd必填goal必填acceptancemax_attemptswait_secondstimeout_minutessupervisor_brief

omp_delegate

Delegate Complete Task to OMP (Low-level)

Low-level background delegation entrypoint. Transfers ownership of an execution task to OMP and returns immediately with job_id. Prefer omp_run_compact for standard workflows to avoid separate delegate/wait round trips.

输入参数cwd必填goal必填acceptancemax_attemptstimeout_minutessupervisor_brief

omp_cancel

Stop OMP Task

Request immediate cancellation of one exact delegated OMP job. The detached runner owns the OMP child PID and terminates that process tree safely. Call this immediately when the user asks to stop; do not inspect PIDs or manually kill processes first.

输入参数job_id必填reason

omp_wait

Wait for OMP Task

Wait for an existing OMP job to reach a terminal status, polling up to wait_seconds (default 30s, max 60s). Returns the current status and summary once terminal or when the wait deadline elapses. Avoid polling in a tight loop.

输入参数job_id必填wait_seconds

omp_result

Inspect Complete OMP Task Result

Retrieve full details of a terminal OMP job, including finalResponse and attempt logs. Call this only when minimal acceptance check fails, high-risk operations occurred, or the user explicitly asks for full inspection; do not call this after every successful compact run.

输入参数job_id必填

omp_continue

Send Supervisory Feedback to Same OMP Session

Resume the same OMP session with targeted supervisory feedback to correct specific acceptance defects without starting a fresh task from scratch. Bounded to remaining attempts within max_attempts.

输入参数job_id必填feedback必填timeout_minutes

版本历史

3
  1. v0.2.1最新Oct 24, 2026
  2. v0.2.0Oct 23, 2026
  3. v0.1.1Sep 16, 2026

评分

已满足适用检查项的 90%

该评分衡量此收录条目的完整程度,依据注册中心条目、端点与公开来源计算得出。它不是对服务器本身的评价,也不表示服务器安全或当前可用:可连通性是带日期的检查结果,评分也不包含安装量或用户评价。

  • 近 30 天内可连通25 分
  • 已声明认证方式10 分

    请在注册中心条目中声明凭据请求头,或保持端点能够响应探测,以便判定其认证方式。

  • 已列出工具必需15 分
  • 描述必需15 分
  • 图标10 分
  • 文档15 分
  • 许可证10 分