Delegates coding tasks to DeepSeek Harness (returns immediately, Codex verifies) — though the project is currently paused and not recommended for deployment.
submit_task — start a coding task with workspace, instruction, and acceptance criteria; returns immediately, multiple tasks may queue or run in parallel.
get_task — read task status and paginated evidence (cursor/limit); a "completed" status is not independent test verification.
wait_task — block on task events or a terminal state (timeout_sec) and return the same task view.
continue_task — send review feedback into the same Harness session; rejects concurrent execution.
cancel_task — stop the owned worker tree; check stopped_confirmed, since edits are never rolled back.
Note: read-only/idempotent annotations apply to get_task and wait_task; task execution requires explicitly passing the current project's absolute path as workspace, and no tool auto-inherits Codex sandbox permissions.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@deepseek_harness Submit a task to fix the failing login tests in src/auth, then wait for it"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
!!! 项目暂停中，在真实生产环境中的压力测试下，本项目并不能表现得很好，具体原因可能在于不同步的上下文、过于广泛的任务描述，使得dsh不仅不能准确完成当下的任务，还要进行多次重复的工作目录探索。这一问题将被重新审视并通过项目架构的调试进行修补与解决。在此之前，不建议部署本项目（悲）
Codex 负责规划与验收，DeepSeek Harness 负责代码修改和测试。
非官方社区 MCP 集成，支持 Windows 和 Ubuntu / WSL。采用 MIT 许可证。
前置条件：需要已经安装codex。不要求一定安装deepseek harness。
Related MCP server: Claude Code Subagent MCP
git clone https://github.com/RichardHu6666/dsh-in-codex.git
cd dsh-in-codex
npm ci
npm run setup默认使用 workspace-write Bubblewrap/Landlock 沙箱并 fail closed。受信任的
Jupyter/GPU 容器若被宿主 seccomp 拦截 unshare(CLONE_NEWUSER)，可在
[mcp_servers.dsh-in-codex.env] 显式设置
HARNESS_MCP_EXECUTION_BACKEND = "direct"；该 unsafe 模式不调用 Bubblewrap
或 Landlock，服务不会在沙箱失败时自动降级。
按终端向导选择用户级或项目级配置、配置密钥和注册 MCP，完成后重载或重启 Codex。 无需单独安装 dsh。需要 Node.js 22.19+、Python 3.11+；系统依赖可让 Codex 协助检查。
直接复制下面整段发给自己的 Codex：
请帮我部署 dsh-in-codex，仓库：
https://github.com/RichardHu6666/dsh-in-codex
目标流程：
git clone https://github.com/RichardHu6666/dsh-in-codex.git
cd dsh-in-codex
npm ci
npm run setup
先确认安装位置与当前 Codex 项目；已有仓库则先检查，不重复克隆或覆盖。
克隆后先阅读 DEPLOYMENT.md 和 SECURITY.md，按当前平台检查环境并处理依赖问题。
系统级安装、全局配置修改前先征求我的确认，不要关闭沙箱或降低审批权限。
setup 是交互式命令，请让我在本机终端完成目录选择、隐藏密钥输入和写入确认。
不要在聊天里索要密钥，不读取或输出已有密钥，也不要把密钥写入命令参数。
如果你无法提供可交互的终端，请给出我需要亲自运行的命令，不要用管道模拟确认。
配置完成后检查 MCP 握手与五个工具：
submit_task、wait_task、get_task、continue_task、cancel_task。
如果当前 Codex 会话还没加载工具，请明确让我重载或重启，不要假装已经调用成功。
握手通过不等于 API Key 有效或 Shell 已可执行；先说明剩余验证项。
得到我对模型费用的确认后，再在独立测试目录做一次最小任务和独立复测。
不要提交、推送、合并或回滚我的项目代码。临时委派，直接对 Codex 说：
这个任务由你规划，通过 dsh-in-codex MCP 交给 DeepSeek 修改代码和运行测试。 你负责检查实际 diff、独立复测和反馈修复；每次委派都必须把当前项目的绝对路径作为
workspace传给 MCP。不要从 MCP 安装目录或服务数据目录推断工作目录。
希望整个项目默认这样协作，就让 Codex：
按 DEPLOYMENT.md 的“项目默认分工”示例，将规则合并到当前项目的 AGENTS.md， 保留原有规则，并检查配套 dsh-in-codex Skill 和 MCP 是否可用。
AGENTS.md 约定默认分工，Skill 描述执行流程，MCP 提供实际工具。
用户级 setup 配置一次即可换项目：Codex 每次委派显式传入当前项目的绝对路径。
项目级 setup 才会限定任务目录；两种模式都不会自动继承 Codex 的沙箱权限。
这不是强制路由：工具不可用时应报告问题，不能假装已经委派。
关闭 MCP 后在本仓库执行 npm run update（详见 DEPLOYMENT.md）。
Stop the owned worker tree. Check stopped_confirmed; edits are never rolled back.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose two valuable traits: cancellation may not be immediate (verify stopped_confirmed) and edits are never rolled back (irreversible side effect). However, it says nothing about permissions, scope of what gets stopped, or partial-failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the action and scope, then the verification and irreversibility caveat. Nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return values need not be explained, and the description usefully points at stopped_confirmed. But for a destructive mutation with zero annotations, the description should say more about authorization and what exactly the 'owned worker tree' covers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the single parameter task_id is never mentioned in the description, so neither source explains what task_id must reference (e.g., a submitted task handle). No meaning is added beyond the schema's type declaration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Stop the owned worker tree.' This clearly distinguishes cancel_task from siblings submit_task/get_task/wait_task/continue_task, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Check stopped_confirmed' gives post-call verification advice but there is no guidance on when to cancel versus wait_task or continue_task, nor any exclusions or prerequisites for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send review feedback to the same Harness session. Rejects concurrent execution.
| Name | Required | Description | Default |
|---|---|---|---|
| task_id | Yes | ||
| feedback | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses only that concurrent execution is rejected; it says nothing about permissions, mutation effects, idempotency, or what happens to the session on success.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with no wasted words; the core action is front-loaded and the concurrency constraint follows immediately. It is appropriately sized for a concise tool note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given two required parameters with no schema descriptions, no annotations, and a mutation-like action, the description is insufficient. It should at least explain task_id and expected feedback, even if return values are covered by the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for both required parameters. The description mentions 'feedback' and 'same Harness session', which faintly contextualizes the feedback and task identity, but task_id is never explained and no format or sourcing guidance is given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Send') and resource ('review feedback') and scopes it to the 'same Harness session', which distinguishes it from submit_task. It is clear enough for an agent to identify the action, though it could more explicitly say it continues an existing task.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'same Harness session' implies usage after a task already exists, and 'Rejects concurrent execution' gives one operational constraint. However, it does not explicitly state when to use this over submit_task or other siblings, leaving alternatives unaddressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read task status and paginated evidence. Completed is not independent test verification.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| task_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only that evidence is paginated and a caution about completed tasks, but doesn't disclose rate limits, auth needs, or what happens on missing tasks. With annotations present, this is modest added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the core action. The second sentence is somewhat cryptic but brief, and there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with a paginated output schema and three parameters, the description is incomplete. It doesn't explain pagination mechanics, how to interpret the output, or the caution about verification in a useful way. The output schema exists, so return values needn't be described, but the behavioral and parameter gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should compensate for three parameters (task_id, limit, cursor). It mentions 'paginated evidence' which hints at limit/cursor, but provides no details on formats, defaults, or the meaning of task_id. Baseline 3 is generous given the coverage gap, but the pagination hint is the only parameter-related signal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a verb (Read) and a resource (task status and paginated evidence), which is clear enough, but it doesn't explain what 'task' means in this context or how it differs from siblings like wait_task or submit_task. The odd second sentence about completed tasks not being independent verification is ambiguous and doesn't clarify purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use get_task versus sibling tools such as wait_task (which likely blocks for completion) or submit_task. The description implies a read operation but offers no conditions for choosing it over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a coding task and return immediately. Multiple tasks may queue or run.
| Name | Required | Description | Default |
|---|---|---|---|
| workspace | Yes | ||
| acceptance | Yes | ||
| instruction | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the key behavioral trait of asynchronous submission ('return immediately') plus concurrency/queueing behavior. It says nothing about idempotency, duplicate submissions, permissions, or failure modes, so a mutation-triggering tool remains only partially characterized.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler, and the async return behavior is front-loaded where it matters most for an agent deciding how to proceed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema presumably documents the returned task handle, so return values need not be explained, and the async semantics are covered. But with no annotations and 0% parameter coverage, the definition leaves the agent guessing about inputs and side effects for a tool that kicks off background work.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across three required parameters (workspace, instruction, acceptance), and the description adds no meaning for any of them. The names are partly self-explanatory, but the shape of 'acceptance' (a string array, presumably criteria) and what 'workspace' refers to are left entirely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Start a coding task') and adds the async qualifier 'return immediately,' which distinguishes it from the blocking sibling wait_task. It stops short of naming or explicitly contrasting with continue_task or cancel_task, so differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Return immediately' plus 'Multiple tasks may queue or run' implies the fire-and-forget pattern where the agent later polls with get_task/wait_task, which is useful implied usage guidance. However, there is no explicit when-to-use versus when-not, and no mention of when continue_task would be the right choice instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wait for task events or a terminal state, then return the same task view.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| cursor | No | ||
| task_id | Yes | ||
| timeout_sec | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds real behavior beyond that by stating it blocks until events or a terminal state and returns the same task view, though it omits any timeout/expiry behavior despite exposing a timeout_sec parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler that states the blocking behavior and the return value up front. It is efficient, though its brevity comes at the cost of the missing semantics noted elsewhere.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not required, but for a blocking wait tool the timeout/limit/cursor semantics are essential and entirely absent. With 0% schema coverage and only one vague sentence, the definition is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across four parameters (limit, cursor, task_id, timeout_sec), yet the description explains none of them. It does not clarify what limit/cursor paginate, nor how timeout_sec governs the wait, leaving the highest-value parameter undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (wait) and resource (task) and clarifies it returns the same task view as a normal read. The 'wait ... for events or a terminal state' phrasing implicitly differentiates it from the sibling get_task, but it never names that sibling, so the distinction relies on inference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use guidance, no mention of get_task as the non-blocking alternative, and no conditions or exclusions. An agent can loosely infer this is the blocking variant, but the description leaves the choice between polling and waiting entirely unstated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0cancel_taskcontinue_taskget_tasksubmit_taskwait_taskScored across 5 tools
Each tool maps to a clearly distinct lifecycle action: start (submit_task), read (get_task), wait (wait_task), interact (continue_task), and stop (cancel_task). The descriptions clarify subtle differences such as immediate read versus waiting for events, and starting a new task versus continuing an existing session.
All five tool names follow a consistent snake_case verb_noun pattern: submit_task, get_task, wait_task, continue_task, cancel_task. There are no deviations or mixed conventions.
Five tools is well-scoped for a task harness, covering the essential lifecycle operations (start, monitor, wait, continue, cancel) without redundancy or missing core actions. Each tool earns its place.
The core task lifecycle is covered: submission, status retrieval, waiting, feedback continuation, and cancellation. However, there is no list_tasks operation to discover queued or running tasks, and no delete/archive operation, which are minor gaps that agents can work around if task IDs are known.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project management MCP for AI agents with safe task reads and writes.
Shared task layer for AI coding agents. One MCP surface: task_search, task_get, task_mutate.
Task tracking built for coding agents. Work is leased, so two agents never take the same SubTask.
