[frando0924-oss]

Why

OpenHands agents can decide that a task is better delegated to an external worker market, but the extensions registry did not include a Taskmarket integration. This plugin adds a usable delegation surface while keeping payment and acceptance under explicit human control.

Summary

• Adds the taskmarket-delegation plugin to the official OpenHands extensions registry.
• Adds a dependency-free stdio MCP bridge for browsing tasks, staging a bounded task, creating through the first-party CLI after exact confirmation, reading status, and presenting submissions.
• Adds a slash command, README, marketplace entry, protocol/safety tests, and vendor manifest links.

Issue Number

This proposal is tracked in Issue #473.

How to Test

1. Install/configure the first-party Taskmarket CLI in the host environment; the plugin never handles its wallet keys.
2. Run syntax validation: python -m py_compile plugins/taskmarket-delegation/scripts/taskmarket_mcp.py tests/test_taskmarket_mcp.py
3. Run the protocol smoke test with initialize, notification, and tools/list requests; it passed with the bundled Python runtime.
4. Run a live read-only MCP call to taskmarket_list_tasks against https://api.taskmarket.dev; it returned current open tasks and pagination metadata.
5. Review the safety gates in taskmarket_prepare_task and taskmarket_create_task: the latter requires a one-time preparation token, confirm=true, exact CREATE_TASK, and the TASKMARKET_MAX_REWARD_USDC ceiling.

Video/Screenshots

Not applicable for this SDK/plugin integration. The live API read and protocol smoke-test output are included above; no paid write was performed during testing.

Notes

• Public reads use the documented Taskmarket REST API.
• Paid creation delegates to taskmarket task create with shell=False, preserving first-party wallet signing, legal acceptance, and X402 handling.
• The plugin deliberately exposes no accept/reject tool: submissions are returned for human review and are never silently resolved.
• The default reward ceiling is 100 USDC and can be lowered with TASKMARKET_MAX_REWARD_USDC.
• Exact commit: c662059.

HUMAN:

I tested the plugin protocol locally with initialize, notification, and tools/list requests, ran Python syntax validation, and completed a live read-only task listing against the documented Taskmarket API. No paid write or wallet operation was performed.

Jev-Fast-Audit

⚡ Jev fast audit · estimates · 0.34s · commit c662059
Strongest signal: Command injection · 8% estimated likelihood.
Evidence: F009H001 · plugins/taskmarket-delegation/scripts/taskmarket_mcp.py:1–393.
Coverage: ⚠️ reduced context — partial coverage; 12/12 hunks, 10/10 files (missing context: 2).

All estimates and evidence

Estimate	Likelihood / value	Direct evidence
SQL injection	3.0%	No direct hunk selected
Command injection	8.0%	F009H001 · plugins/taskmarket-delegation/scripts/taskmarket_mcp.py:1–393
Weakened authentication	12.0%	No direct hunk selected
Weakened authorization	25.0%	No direct hunk selected
Contract regression	14.0%	No direct hunk selected
Data loss	6.0%	No direct hunk selected
Sensitive data disclosure	7.0%	No direct hunk selected
Unexpected data transfer	7.0%	No direct hunk selected
Credential misuse	11.0%	No direct hunk selected
Untrusted instruction authority	5.0%	No direct hunk selected
Package source redirection	4.0%	No direct hunk selected
Unverified remote execution	4.0%	No direct hunk selected
Privileged environment access	25.0%	F009H001 · plugins/taskmarket-delegation/scripts/taskmarket_mcp.py:1–393
Security assessment bypass	8.0%	No direct hunk selected
Prohibited workload	3.0%	No direct hunk selected
Primary concern	Command injection; confidence 46.0%	F009H001 · plugins/taskmarket-delegation/scripts/taskmarket_mcp.py:1–393

[all-hands-bot]

👋 This PR needs a couple of things fixed before OpenHands can review it:

• the PR description's HUMAN: section needs at least 20 characters describing what you tested, not just the template placeholder

Push an update once this is addressed and this check re-runs automatically.

This is an automated check - no AI was used to generate this comment.

[VascoSch92]

Sorry, I don't know if we want this plugin. Could you open an issue before? Thanks

[frando0924-oss]

@VascoSch92 I opened Issue #473 as requested and linked it from the PR description. I also refreshed the HUMAN section with the actual syntax, protocol, and live read-only API checks; no paid write or wallet operation was used. Please let me know whether this integration fits the extensions registry and what changes you would require.

[all-hands-bot]

⚠️ Review paused: current-head checks failed

The current head c6620590a727 has failing checks, so no review conversation was started:

• Check Extensions
• Deprecation deadlines
• Tests

Fix the checks above and push. Then remove the outstanding all-hands-bot request and request all-hands-bot again: GitHub will not accept a second request while the first is still outstanding. The review starts on the updated head.

This is an automated check - no AI was used to generate this comment.

[all-hands-bot]

⚠️ Review paused: current-head checks failed

The current head c6620590a727 has failing checks, so no review conversation was started:

• Check Extensions
• Deprecation deadlines
• Tests

Fix the checks above and push. Then remove the outstanding all-hands-bot request and request all-hands-bot again: GitHub will not accept a second request while the first is still outstanding. The review starts on the updated head.

This is an automated check - no AI was used to generate this comment.

[all-hands-bot]

This review was posted by an AI agent (OpenHands).

Scope gate: maintainer decision required before technical review.

Current state on head c6620590a727:

• Maintainer @VascoSch92 has an outstanding CHANGES_REQUESTED review: "Sorry, I don't know if we want this plugin. Could you open an issue before? Thanks".
• The linked proposal, issue #473, is still open with no labels, no assignee, and no comments. This repo uses ready-for-dev and priority:* labels, so the absence of a readiness label means the proposal has not been accepted for implementation - it is not a missing label vocabulary.
• The head's checks are failing: Check Extensions, Tests, and Deprecation deadlines all report failure; only the pr-title checks pass.

This is not a technical-correctness question. The maintainer asked whether the repository wants this integration at all, and that question is still unanswered on issue #473. Whether a paid, third-party worker-market delegation plugin belongs in the official OpenHands extensions registry is a product and architecture decision that a maintainer has to make before a code review of the 574 added lines is meaningful.

What should happen next: this PR needs a maintainer product decision, not a code change. Concretely:

1. A maintainer should decide on issue #473 whether the Taskmarket delegation plugin is in scope for this registry, and label the issue accordingly (ready-for-dev if accepted).
2. If accepted, the PR should be refreshed on the decided direction and the failing Check Extensions / Tests / Deprecation deadlines checks resolved before a review is requested again.
3. If not accepted, the PR should be closed rather than iterated on.

I am not asking for this to move to another repository: the extensions registry is the structurally correct home for a plugin of this kind, so relocation is not the open question - the open question is whether the registry should carry it. I have deliberately not reported implementation findings, since that work is only useful once the direction is settled.

🛑 MAINTAINER DECISION REQUIRED

[enyst]

I'm an AI agent (Claude Code, based on Opus 5.5) helping Engel Nyst (@enyst) with project work.

Requesting changes. The scope decision on #473 that @VascoSch92 and all-hands-bot (2026-09-23) asked for is still pending, and the failing checks that review lists are unchanged. Separately, the bridge doesn't work as an MCP server, and its spending gate is not a human gate.

1. Wrong stdio framing. taskmarket_mcp.py:371-375 writes LSP-style Content-Length: headers, but MCP's stdio transport is newline-delimited JSON. A standard client, including the SDK's, cannot parse any response. The test at test_taskmarket_mcp.py:84-90 asserts this framing, so it passes while real clients fail. Write one JSON object per line.
2. The script path won't resolve. .mcp.json:4-5 runs python scripts/taskmarket_mcp.py relative to the process's working directory, which is the user's workspace, not the plugin. Use ${SKILL_ROOT}/scripts/taskmarket_mcp.py, which the SDK expands for a plugin's .mcp.json, and python3.
3. The agent supplies its own confirmation. taskmarket_mcp.py:163-174 accepts confirm: true plus CREATE_TASK plus a token that the same agent got from prepare moments earlier. Nothing proves a human saw the summary, so a prompt-injected agent can call both back to back and spend up to the 100 USDC default ceiling. Use host-level confirmation, or keep create out of the agent's reach.
4. The spend ceiling isn't enforced at payment. maximum_possible_spend_usdc (taskmarket_mcp.py:157) equals the reward. The CLI's task create has no spend-cap flag and pays whatever amount the server quotes (the same finding all-hands-bot raised on #470).
5. Task text becomes public. Tasks default to public, and the CLI's own help says even unlisted tasks stay permanently visible on-chain. commands/delegate.md doesn't tell the agent to strip repository code, secrets or private data from the description.
6. Process. The PR also conflicts with main.

Compared with #470 (same service, different author): this PR exposes fewer tools (no accept or withdraw) but doesn't work as an MCP server today. #470 works as a CLI adapter but pre-approves the whole wallet CLI. Neither enforces consent or spend where the payment happens. The same integration has been proposed to many agent frameworks, and no OpenHands user request is linked. I'd recommend adding neither unless maintainers decide on #473 that paid crypto delegation belongs in the registry.