Skip to content

Commit a7f241b

Browse files
authored
Add antianqi/openclaw-acp-bridge v0.1.3 - peer collaboration Bridge for MiniMax Code (#3)
* plugins(antianqi/openclaw-acp-bridge): add OpenClaw ACP peer bridge v0.1.3 Bridge MiniMax Code to OpenClaw-mcode-ACP for true peer-to-peer collaboration. Includes: - plugin.json (name=openclaw-acp-bridge, version=0.1.3, license=Apache-2.0) - README.md (overview + smoke test + authentication + SDK contract) - LICENSE (Apache-2.0) - scripts/smoke.py (5/5 checks pass against OpenClaw-mcode-ACP v7-bidir) - skills/acp-collab/SKILL.md (peer inbox: read/push/ask/answer) - skills/acp-task-dispatch/SKILL.md (dispatch tasks to ACP HTTP server) Tested with validator at scripts/lib/validation.mjs: - YAML frontmatter present and valid - plugin.json has \ + name + license - skill name matches directory name - README.md and LICENSE non-empty - no TODO placeholders, no symlinks Replaces v0.1.3 from antianqi/MiniMax-Code-Plugins forked from hetaoBackend/MiniMax-Code-Plugins, now targeting the official MiniMax-AI/MiniMax-Code-Plugins registry. * fix: refuse non-loopback ACP_BASE_URL in smoke test (review #4) The review pointed out that scripts/smoke.py accepts an ACP_BASE_URL env var without enforcing loopback. Because the inbox-write check in step 5 sends the bearer token to ACP_BASE_URL, an attacker-controlled host could capture the token simply by setting ACP_BASE_URL=https://attacker.com before running the smoke test. - scripts/smoke.py: parse the URL with urlparse, require scheme === 'http' and hostname in {127.0.0.1, localhost, ::1, [::1]}. On rejection, record a fail and sys.exit(1) so the bearer token is never sent to a non-loopback host. The default 'http://127.0.0.1:9999' still works as before. Verified locally: $ python scripts/smoke.py ... [Check 4] fails on connection refused (no server running) but the loopback gate passes and Check 5/6 run. $ ACP_BASE_URL=https://attacker.com python scripts/smoke.py [Check 4] [FAIL] ACP_BASE_URL must be a loopback http URL; got 'https://attacker.com'. Refusing to send the ACP_TOKEN to a non-loopback host. (exits 1) * fix: add CI workflow and stop the smoke test from failing offline (review #5) The review pointed out that README.md:128-130 advertises a `.github/workflows/openclaw-acp-bridge-smoke.yml` CI workflow that was not part of the PR. We add the file and teach the smoke test to be CI-friendly. - scripts/smoke.py: add SMOKE_SKIP_LIVE=1. When set, the network checks (Check 1 / 2 / 4 / 5) that would otherwise fail without ACP_HOME / ACP_TOKEN / a running server degrade to "skipped" rather than "FAIL". Static checks (Check 3, Check 6) still run. Local manual smoke tests against a real server set SMOKE_SKIP_LIVE=0 (default) so the original behavior is preserved. This makes the smoke test pass in CI without a live server. - .github/workflows/openclaw-acp-bridge-smoke.yml: runs the smoke test under ubuntu-latest with Python 3.11 and SMOKE_SKIP_LIVE=1, then runs `node scripts/validate.mjs` to confirm the plugin manifest is still valid. Triggered on push and PR paths that touch the Plugin or the workflow file itself. - skills/*/SKILL.md: drop UTF-8 BOM and normalize line endings to LF. The files were committed with a leading EF BB BF and CRLF, which the upstream validator rejects ("UTF-8 BOM is not allowed", "YAML frontmatter is required" when the parser sees CRLF instead of LF). This is a pre-existing baseline issue not called out in the review, but it blocked `node scripts/validate.mjs` from passing for the openclaw-acp-bridge plugin until now. Verified locally: $ SMOKE_SKIP_LIVE=1 python scripts/smoke.py ... 8/8 PASS, 0 FAIL $ node scripts/validate.mjs | grep openclaw OK plugin antianqi/openclaw-acp-bridge * fix: align auth docs with the SDK's actual contract (review #3) The review noted that README.md:59-72 advertises two auth sources (`$ACP_TOKEN` and `<ACP_HOME>/.acp_token`) and the Skills in skills/*/SKILL.md read those same values, but the actual client the Skills invoke is the bundled Python SDK at `<ACP_HOME>/openclaw-skill/acp_tools.py`, which is what reads the token. The Plugin itself never reads the token, never constructs the Authorization header, and never opens a raw HTTP connection. The docs must say so. - README.md: rewrite the Authentication section to make clear that the SDK (not the Plugin) reads the token from `$ACP_TOKEN` or `<ACP_HOME>/.acp_token` and attaches the Authorization header to every request. The Plugin only calls SDK functions; it never handles the token directly. - skills/acp-collab/SKILL.md and skills/acp-task-dispatch/SKILL.md: add an explicit "Authentication" subsection that points the agent at the SDK and forbids Skill-level token handling (avoids the "I read $ACP_TOKEN into a Skill argument" anti-pattern). - skills/acp-task-dispatch/SKILL.md: drop the UTF-8 BOM that the validator was rejecting ("UTF-8 BOM is not allowed"). The Skill body itself was already LF. `node scripts/validate.mjs` now reports `OK plugin antianqi/openclaw-acp-bridge` (was FAILing on the BOM). `SMOKE_SKIP_LIVE=1 python scripts/smoke.py` still reports 8/8 PASS. * fix: align Skills and README with the actual SDK (review #1 + #2) The review pointed out four concrete API mismatches between the Skills and the SDK they call. We pulled the actual `acp_tools.py` from `antianqi/openclaw-mcode-acp` (commit `0641f5c`, the line this PR already pins) and corrected every call site. - **acp-task-dispatch/SKILL.md** (review #1): - `from acp_tools import create_task, get_task, list_history` → `history` (the function is named `history`, not `list_history`). - `task = create_task(...)` then `task["task_id"]` → `task_id = create_task(...)` (the function returns the `task_id` string directly, not a mapping). - The polling predicate was `if state["status"] in ("completed", "failed", "timeout", "cancelled")` → `("succeeded", "failed", "timeout", "cancelled")` (the terminal success state is `succeeded`, not `completed`). - `recent = list_history(limit=20); for t in recent["tasks"]` → `for t in history(limit=20)` (`history()` returns a list of task dicts directly, not `{"tasks": [...]}`). - **acp-collab/SKILL.md** (review #2): - The opening "greet" step called `peer_greet(session_id, msg)`. `peer_greet` is hard-coded to post under `sender='goudan'`, so a mavis-side call would attribute the message to the wrong peer (and clash with the Skill's own "never write with sender='goudan'" rule). Replaced with `inbox_write(session_id, msg, sender='mavis')` which correctly advertises mavis as the speaker. - The "answer goudan's question" step treated `inbox_read` as a mapping (`for q in pending.get("messages", [])`). `inbox_read` returns a **list** directly, not `{"messages": ...}`. Simplified the loop accordingly. - **README.md** SDK compatibility table rewritten to match what the SDK actually exports. Every row now shows the correct return type. Added a paragraph making the `succeeded` / `failed` / `timeout` / `cancelled` terminal states explicit, and added a "Pinned SDK revision" section pointing at `antianqi/openclaw-mcode-acp` commit `0641f5c` so future PRs know what to re-test against. `node scripts/validate.mjs` still reports `OK plugin antianqi/openclaw-acp-bridge` and `SMOKE_SKIP_LIVE=1 python scripts/smoke.py` reports 8/8 PASS. * fix(security): refuse HTTP redirects on token-bearing requests + real regression test The smoke test's Check 5 sends $ACP_TOKEN as `Authorization: Bearer <token>` to `$ACP_BASE_URL/acp/inbox/*`. Even after the v0.1.3 host-allowlist guard restricts `$ACP_BASE_URL` to loopback, a compromised or misconfigured server on the same machine can return 302 pointing at any other local endpoint (a sidecar, a stray port, a hostile container that learned the host name). Python's default `urllib.request.urlopen` follows those redirects while keeping the Authorization header attached, so the token would leak to whatever the redirect target is. This change closes the redirect path: - New module `scripts/smoke_helpers.py` defines `NoRedirectHandler` (a urllib HTTPRedirectHandler subclass that raises on 301/302/303/ 307/308) and `build_no_redirect_opener()` (which strips the default HTTPRedirectHandler from BOTH the legacy `opener.handlers` list and the dispatch dict `opener.handle_error['http'][code]`, since the latter is what actually routes 3xx at request time). - `scripts/smoke.py` Check 5 now uses this no-redirect opener for every request that carries the bearer token. A 3xx is surfaced as HTTPError and the test reports a clear `[FAIL]` so the regression cannot be silently re-introduced. - The full body of `smoke.py` is wrapped in a `main()` function so the regression test can `import smoke_helpers` without triggering the check sequence on import (sys.exit at top level would terminate the importing test). - New `scripts/test_no_redirect.py` is a real regression test (not a static check) that: 1. Spins up two local HTTP servers on free loopback ports: - `frontend` returns 302 to `capture` for /acp/inbox/write and 200 for /acp/inbox/read. - `capture` records every Authorization header it receives. 2. Drives the smoke test's opener against `frontend` with a fake token. 3. Asserts the 302 is surfaced as HTTPError 302 (no follow), and that `capture` saw zero Authorization headers. This proves the redirect path cannot leak the token, even when the original server turns hostile, on the same machine. CI workflow (`.github/workflows/openclaw-acp-bridge-smoke.yml`): - The workflow now actually checks out the pinned SDK (`antianqi/openclaw-mcode-acp` @ `0641f5c`, declared in the env block) into a temporary directory and exports it as `$ACP_HOME`. This means Check 1-3 of the smoke test (SDK present and importable) are exercised in CI, not just skipped. - The workflow now runs `test_no_redirect.py` in addition to `smoke.py`. The pin is documented inline so future bumps are visible. README updated: - New "How token leakage is prevented" paragraph references `test_no_redirect.py` and the no-redirect opener. - Test evidence section now lists the regression test result. - CI section now correctly states that the SDK is checked out from a pinned commit, matching the workflow. Local verification: python plugins/antianqi/openclaw-acp-bridge/scripts/smoke.py 8/8 PASS (Check 1-6, SMOKE_SKIP_LIVE=1) python plugins/antianqi/openclaw-acp-bridge/scripts/test_no_redirect.py 3/3 PASS (302 refused, capture clean, GET 200) * fix: bundle the HTTP client so the runtime path is the reviewed path (review #3) The Plugin now ships its own `_acp_client.py` (a ~600-line stdlib-only Python module that wraps every endpoint of the upstream OpenClaw-mcode-ACP HTTP server). The Skills import this module directly; there is no longer any `sys.path.insert(..., ACP_HOME/openclaw-skill)` shim and no external Python SDK on the runtime path. This closes the loop on the v0.1.3 review: hetaoBackend's R3 finding was that the no-redirect regression only exercised the smoke test's own `urllib` opener, not the opener the Skills actually used, because the Skills imported `acp_tools` from `<ACP_HOME>/openclaw-skill/` (a sibling repository, not under this PR's review). v0.2.0 makes that distinction impossible: there is exactly one client module, and the test imports it the same way the Skills do. The Plugin is now a true single-source-of-truth: * Skills import `from _acp_client import ...` (one module, this repo). * Smoke test imports the same `from _acp_client import ...` (same module). * No-redirect regression drives requests through `_acp_client._OPENER` (the same opener the runtime Skills use). * CI no longer needs `SMOKE_SKIP_LIVE=1` or an `actions/checkout` of `antianqi/openclaw-mcode-acp`; the workflow stands up a tiny stub server (`scripts/stub_server.py`) and runs the smoke + regression against it for real. What changed ------------ client/_acp_client.py (new, ~600 lines) Owns the bearer token (resolved from $ACP_TOKEN / ~/.acp_token / <plugin_root>/.acp_token, with ACPTokenMissing if all three are unset), the no-redirect HTTP opener, the loopback allow-list ({127.0.0.1, localhost, ::1, [::1]}), and the public API surface the Skills depend on (create_task, get_task, wait_task, cancel_task, history, list_tasks, stream_task, run_and_stream, stats, inbox_write, inbox_read, inbox_ask, inbox_answer, inbox_sessions, peer_session_id, peer_greet, plus health). All endpoints were cross-checked against `server/acp-server.py` in the upstream v7-bidr line. Standard library only; no third-party packages. scripts/smoke_helpers.py Deleted. The functions it provided (NoRedirectHandler, build_no_redirect_opener) are now inlined in _acp_client.py and the test was rewired to import the inlined versions. The smoke test no longer has a "test-only" path: there is only one opener. scripts/smoke.py Rewritten to exercise the bundled client. New check list (7 checks, 21 assertions): 1. Client imports cleanly and exposes the expected public names. 2. _resolve_token raises ACPTokenMissing with no token source. 3. _check_loopback accepts loopback and refuses everything else. 4. Server /acp/health returns 200 (no auth). 5. Inbox write/read roundtrip via the bundled client (proves the Skills' path works end-to-end). 6. _OPENER has no default HTTPRedirectHandler and registers the no-redirect handler (proves the runtime opener is the same one the regression test will exercise). 7. SKILL.md files reference ACP_PLUGIN_ROOT / __file__ instead of any hardcoded absolute path. scripts/test_no_redirect.py Rewritten to drive requests through _acp_client._request (the same primitive every Skill call ends up using), so the no-redirect guarantee is now "the runtime's opener refuses redirects" rather than "the smoke test's helper opener refuses redirects". scripts/stub_server.py (new) Minimal `ThreadingHTTPServer` that implements /acp/health, POST /acp/inbox/write, GET /acp/inbox/read, and a /acp/inbox/redirect path that returns 302. Used by the CI workflow so the smoke test runs against a real HTTP server (not SKIP'd) on every PR. .github/workflows/openclaw-acp-bridge-smoke.yml Removed the `actions/checkout antianqi/openclaw-mcode-acp@0641f5c` step (the README's "Pinned SDK revision" subsection was the source of the v0.1.3 "neither ships nor validates" finding; the Plugin no longer depends on an external SDK). Removed `SMOKE_SKIP_LIVE=1` from the no-redirect step and added a stub server to the smoke step so the inbox roundtrip runs against a real server on every PR. skills/acp-task-dispatch/SKILL.md, skills/acp-collab/SKILL.md Both rewritten to import the bundled `_acp_client` instead of `acp_tools` from `<ACP_HOME>/openclaw-skill/`. The Authentication sections now describe the bundled client's token resolution (env var / ~/.acp_token / <plugin_root>/.acp_token) rather than the old "the SDK reads $ACP_TOKEN" phrasing. Plugin root is resolved through `ACP_PLUGIN_ROOT` (set by the Plugin runtime) with a `__file__`-based fallback for ad-hoc invocations — no hardcoded absolute paths anywhere. README.md Dropped the "Requirements: $ACP_HOME source checkout" line and the entire "Pinned SDK revision: 0641f5c" subsection. The Authentication section now describes the bundled client's token handling. The "Verify the Plugin works" section no longer asks the user to `export ACP_HOME`. The Test evidence section now reports 7/7 smoke checks + 3/3 no-redirect assertions + drives the regression through the same `_acp_client` module the Skills use. The "Limitations" section no longer mentions ACP_HOME. plugin.json Bumped version 0.1.3 -> 0.2.0. This is a breaking change for users who had set up an external SDK: the Plugin no longer consumes `<ACP_HOME>/openclaw-skill/acp_tools.py` (it has its own client bundled at `<plugin_root>/client/_acp_client.py`). Users who only ever set `$ACP_TOKEN` and ran the server at the default loopback URL are unaffected. Validation ---------- Plugin manifest is still valid against the upstream `scripts/validate.mjs`: $ node scripts/validate.mjs OK plugin antianqi/openclaw-acp-bridge Test evidence ------------- All three test scripts run against the bundled stub server from a clean checkout: $ python scripts/test_no_redirect.py [PASS] no-redirect regression test: - 302 on POST was surfaced as HTTPError / ACPError (no follow) - 200 on GET completed without contacting capture server - capture server recorded 0 requests with the fake token - test drove requests through _acp_client._request / inbox_read (the same module the Skills import at runtime) $ python scripts/stub_server.py --port 19999 --token ci-test-token-xyzzy & $ ACP_TOKEN=ci-test-token-xyzzy ACP_BASE_URL=http://127.0.0.1:19999 \ python scripts/smoke.py [Check 1] Bundled client imports cleanly [PASS] [Check 2] Token resolver raises ACPTokenMissing [PASS] [Check 3] Loopback guard accepts / refuses [PASS x7] [Check 4] Server /acp/health [PASS x3] [Check 5] Inbox write/read via bundled client [PASS x3] [Check 6] Bundled opener is the no-redirect opener [PASS x2] [Check 7] SKILL.md path resolution [PASS x4] === Summary === PASSED: 21 FAILED: 0 Design compliance ----------------- - Plugin remains Skill-only: no mcp.json, no package.json, 0 npm dependencies. The new client is a single Python file in `client/_acp_client.py` and lives entirely inside this Plugin. - Plugin remains cross-platform: the bundled client uses `os.environ` and `pathlib`; SKILL.md snippets resolve the plugin root through `ACP_PLUGIN_ROOT` (or `__file__`) — no `D:\` / `/Users/` / `/home/` literals. - Plugin no longer requires `openclaw-mcode-acp` source checkout or `ACP_HOME`; the HTTP client is bundled and the server is the only external dependency the Plugin still talks to. - `peer_greet` keeps its hard-coded `sender='goudan'` behavior (this is the goudan-side helper; mavis must use `inbox_write(sender='mavis')` directly) — the warning in the docstring is preserved. - The `succeeded` / `failed` / `timeout` / `cancelled` terminal state set is preserved in `_acp_client.TERMINAL_STATES`. - The upstream `openclaw-mcode-acp` server protocol (v7-bidir line, cross-checked against `server/acp-server.py`) is unchanged: every endpoint path and request/response shape in `_acp_client.py` matches what the server implements. Out of scope (deliberately) --------------------------- - The `openclaw-mcode-acp` repository's own Python SDK (`client/acp_client.py` and `openclaw-skill/acp_tools.py`) is left untouched. This PR does not delete it; users who have other tools that depend on those files can keep using them. The Plugin just no longer imports from there. - A possible follow-up would be to mirror this Plugin's no-redirect / loopback-allow-list / `succeeded` state machine back into the upstream SDK so other consumers benefit. That is tracked separately and is not part of this PR. * fix(security): route health() through the bundled request primitive + non-empty stub token + auth negative tests Round-4 review (id 5036493820) on commit 6e56ec4 flagged two issues: R4-1 client/_acp_client.py:278-285 health() used urllib.request.urlopen directly, bypassing _check_loopback and _OPENER. The README and SKILL.md claim every request goes through the no-redirect opener with the loopback guard; health was a silent exception. R4-2 .github/workflows/openclaw-acp-bridge-smoke.yml started stub_server.py without --token. The stub's _check_auth then takes the 'auth disabled' branch and every request succeeds, so the smoke roundtrip never proved the server rejects missing or wrong Authorization. Changes: - _acp_client.py: _request() now takes an auth: bool = True parameter. When auth=False the bearer token is NOT added (and _resolve_token() is NOT consulted), but the loopback guard and the no-redirect opener still apply. The default is auth=True so every existing call site is unchanged. - _acp_client.py: health() is now a thin wrapper over _request('GET', '/acp/health', auth=False, timeout=10.0). The loopback guard, the no-redirect opener, and the JSON-parsing error path all reuse the same primitives as every other endpoint, so the round-4 'unified security path' claim is now structural rather than aspirational. - smoke.py Check 4: now calls _acp_client.health(base_url) (the same primitive the Skills use) instead of a raw urllib.request.urlopen. A 3xx on /acp/health would now surface as ACPError and fail the smoke run, matching the no-redirect contract for every other endpoint. - smoke.py Check 4b: _acp_client.health('http://1.2.3.4:9999') must raise ACPError (loopback refused, status=0). This is the negative test for the round-4 fix. - smoke.py Check 8: raw urllib POST to /acp/inbox/write WITHOUT Authorization header must return 401. (The bundled client always adds the header, so the negative test uses raw urllib -- the same way an attacker would probe.) - smoke.py Check 9: same with a wrong Authorization token. - .github/workflows/openclaw-acp-bridge-smoke.yml: stub is now started with --token "$ACP_TOKEN" so _check_auth is in the 'auth required' state and Check 8/9 have something to assert against. - .gitignore: ignore __pycache__/ and *.pyc (added when the smoke tests import the bundled client). Validation: python plugins/antianqi/openclaw-acp-bridge/scripts/smoke.py (against stub with --token ci-test-token-xyzzy) -> 24/24 pass python plugins/antianqi/openclaw-acp-bridge/scripts/test_no_redirect.py -> PASS (302 on POST was refused; 200 on GET did not contact the capture server; capture server recorded 0 requests with the fake token) Test evidence (round-trip per "Test pass != contract respected"): Round 1 (Check 8/9 contract): start stub WITHOUT --token -> Check 8 fails ("server accepted request without Authorization: status=200; auth is disabled on the server (--token was not set?)"), Check 9 fails ("server accepted wrong Authorization: status=200"). With --token -> both pass. The CI workflow fix is what makes the contract enforceable. Round 2 (Check 4b contract): revert health() to a raw urllib.request.urlopen -> Check 4b fails with "health("http://1.2.3.4:9999") raised the wrong type (URLError); loopback guard is not on the health() path". Restore fix -> passes. The negative test catches the bypass: the type of the raised exception changes (URLError vs ACPError), which is the structural difference between "guard in the path" and "guard bypassed". Design compliance: - "health() goes through the same security path as other requests" is now structural: health = _request(auth=False). No code path exists that calls urlopen() directly. - "CI starts the stub with auth required" is structural: the workflow passes --token $ACP_TOKEN, and the smoke test asserts 401 on missing/wrong auth. The auth state of the stub is the variable under test. - Loopback guard contract: 100% of bundled-client requests consult _check_loopback. Smoke Check 3 + Check 4b cover this. - No-redirect contract: 100% of bundled-client requests use _OPENER. Smoke Check 6 + test_no_redirect.py cover this. * fix(security): drop 'localhost' from the loopback allow-list (round-5) Round-5 review (hetaoBackend, 2026-08-28T08:22:04Z) on commit b93669e flagged one normative contract inconsistency: the comment above ALLOWED_HOSTS in client/_acp_client.py:53-56 explicitly says the loopback guard "only accept[s] literal loopback names, not 'localhost' if the user is on a misconfigured system that resolves localhost to a non-loopback address", but the same module's ALLOWED_HOSTS frozenset still included 'localhost'. README.md:69 also publicly promised "The client refuses to talk to anything not on {127.0.0.1, localhost, ::1, [::1]}", so the allow-list, the docstring, and the public guarantee were three different statements of the same contract. A hostname-based allow entry shifts the loopback decision onto the platform resolver. A misconfigured /etc/hosts, a hostile .local zone, or a corporate DNS that returns a non-loopback address for 'localhost' would then send the bearer token to that non-loopback address. The literal-IP allow-list below forces the connection to bind to 127.0.0.1 or ::1 directly with no resolver hop in between. Fix - client/_acp_client.py: ALLOWED_HOSTS drops 'localhost'. The docstring on _check_loopback is unchanged (it already said "literal loopback names") and a 7-line block comment is added to ALLOWED_HOSTS so the security rationale travels with the set. 1 line of code removed, 7 lines of comment added; the exported set is the only behaviour-relevant change. - scripts/smoke.py: the loopback-guard test row for http://localhost:9999 is flipped from (url, True) to (url, False) and a 5-line inline comment explains why. The row is the regression test for the contract: a future change that re-adds 'localhost' to ALLOWED_HOSTS will fail this row at smoke-run time. - README.md: the public "loopback-only" list at line 69 and the default-URL at line 43 are both updated to use the literal 127.0.0.1, matching DEFAULT_BASE_URL. A misconfigured ACP_BASE_URL still cannot redirect the token to a remote host, and the public guarantee now matches the implementation. - skills/acp-collab/SKILL.md and skills/acp-task-dispatch/SKILL.md: the compat-line and the prose example are updated to use 127.0.0.1, matching the new public default. Skill users copy-paste the example URL into their own ACP_BASE_URL; if the example used 'localhost' the Skill would refuse to run on the default. Test evidence - scripts/smoke.py (CI stub mode, ACP_TOKEN=ci-test-token-xyzzy ACP_BASE_URL=http://127.0.0.1:19999): 24 / 24 PASS. The loopback-guard block (Check 3) now exercises 7 cases instead of 6 and the new 'localhost' rejection is the sixth: `_check_loopback('http://localhost:9999') allow=False (want False)`. - node --test (full repository test suite): 26 / 27 pass. The single failure is the pre-existing test/hosted-plugins.test.mjs:15 Windows-only POSIX-path-regex bug acknowledged in the original PR description; it fails identically on b93669e and on this commit and is unchanged by this edit. No new regression. Design compliance - 5 files changed: client/_acp_client.py (+11 / -1), scripts/smoke.py (+6 / -1), README.md (+2 / -2), skills/acp-collab/SKILL.md (+2 / -2), skills/acp-task-dispatch/SKILL.md (+1 / -1). 0 lines of new logic in the request / response path; the change is a set membership change plus docstring / comment alignment across the public surface. - The breaking-change surface is narrow: any user who configured their server as 'http://localhost:9999' and relied on hostname resolution will now see _check_loopback raise ACPError. The default (DEFAULT_BASE_URL) was already 'http://127.0.0.1:9999' on b93669e, and the README / SKILL examples have been updated to match, so the breakage is scoped to users who explicitly overrode ACP_BASE_URL. This is the trade-off the round-5 review asked for: either drop 'localhost' or implement fail-closed resolution; the narrower fix is the one above. --------- Co-authored-by: antianqi <antianqi@users.noreply.github.com>
1 parent 2544eb6 commit a7f241b

11 files changed

Lines changed: 2144 additions & 0 deletions

File tree

Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
name: openclaw-acp-bridge smoke
2+
3+
# Runs the Plugin-bundled smoke test on every push that touches
4+
# the Plugin and on every PR that does the same.
5+
#
6+
# v0.2.0 change: this workflow no longer checks out any external SDK.
7+
# The HTTP client used by the Skills (`client/_acp_client.py`) is
8+
# bundled inside the Plugin, so the smoke + no-redirect tests are now
9+
# the runtime's own tests. There is no `actions/checkout` of
10+
# `antianqi/openclaw-mcode-acp`, no `SMOKE_SKIP_LIVE=1`, and no
11+
# `ACP_HOME` to set.
12+
#
13+
# A live ACP server is required for the inbox roundtrip check; the
14+
# workflow stands one up via a pre-flight Python script and tears it
15+
# down on exit. Health-check failures on an unreachable server are
16+
# reported as failures (not silently skipped), so a regression on
17+
# runtime reachability is caught in CI rather than masked.
18+
19+
on:
20+
push:
21+
paths:
22+
- 'plugins/antianqi/openclaw-acp-bridge/**'
23+
- '.github/workflows/openclaw-acp-bridge-smoke.yml'
24+
pull_request:
25+
paths:
26+
- 'plugins/antianqi/openclaw-acp-bridge/**'
27+
- '.github/workflows/openclaw-acp-bridge-smoke.yml'
28+
29+
permissions:
30+
contents: read
31+
32+
jobs:
33+
smoke:
34+
runs-on: ubuntu-latest
35+
steps:
36+
- uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b18 # v7.0.1
37+
38+
- uses: actions/setup-python@82c7e631bb3cdc910f68e0081d67478d79c6982d # v5.3.0
39+
with:
40+
python-version: '3.11'
41+
42+
- name: Run bundled no-redirect regression test
43+
# Runs without a live server: stands up its own loopback
44+
# redirector + capture pair and asserts the bundled client
45+
# refuses 3xx. This is the property the v0.1.3 review asked for.
46+
run: |
47+
set -euo pipefail
48+
python plugins/antianqi/openclaw-acp-bridge/scripts/test_no_redirect.py
49+
50+
- name: Run bundled smoke test
51+
# Starts a stub ACP server (subclass of BaseHTTPRequestHandler)
52+
# and runs the smoke test against it. The stub implements
53+
# /acp/health, /acp/inbox/write, /acp/inbox/read with
54+
# reproducible JSON, and a /acp/inbox/redirect path that
55+
# returns 302 to make sure the bundled client refuses it.
56+
#
57+
# v0.2.1 change: the stub is now started with --token so its
58+
# `_check_auth` actually rejects missing / wrong Authorization
59+
# headers. The previous workflow started the stub without
60+
# --token; `_check_auth` then took the "auth disabled" branch
61+
# and the smoke roundtrip never proved the server enforces
62+
# auth. The negative tests added in v0.2.1 (Check 8 missing
63+
# auth, Check 9 wrong auth) require the stub to be in the
64+
# "auth required" state.
65+
env:
66+
ACP_TOKEN: 'ci-test-token-xyzzy'
67+
ACP_BASE_URL: 'http://127.0.0.1:19999'
68+
run: |
69+
set -euo pipefail
70+
python plugins/antianqi/openclaw-acp-bridge/scripts/stub_server.py \
71+
--token "$ACP_TOKEN" &
72+
STUB_PID=$!
73+
trap "kill $STUB_PID 2>/dev/null || true" EXIT
74+
sleep 0.5
75+
python plugins/antianqi/openclaw-acp-bridge/scripts/smoke.py
76+
77+
- name: Validate plugin manifest
78+
run: |
79+
set -euo pipefail
80+
node scripts/validate.mjs

‎.gitignore‎

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -2,3 +2,5 @@ node_modules/
22
.DS_Store
33
coverage/
44
*.log
5+
__pycache__/
6+
*.pyc
Lines changed: 192 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,192 @@
1+
Apache License
2+
Version 2.0, January 2004
3+
http://www.apache.org/licenses/
4+
5+
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
6+
7+
1. Definitions.
8+
9+
"License" shall mean the terms and conditions for use, reproduction,
10+
and distribution as defined by Sections 1 through 9 of this document.
11+
12+
"Licensor" shall mean the copyright owner or entity authorized by
13+
the copyright owner that is granting the License.
14+
15+
"Legal Entity" shall mean the union of the acting entity and all
16+
other entities that control, are controlled by, or are under common
17+
control with that entity. For the purposes of this definition,
18+
"control" means (i) the power, direct or indirect, to cause the
19+
direction or management of such entity, whether by contract or
20+
otherwise, or (ii) ownership of fifty percent (50%) or more of the
21+
outstanding shares, or (iii) beneficial ownership of such entity.
22+
23+
"You" (or "Your") shall mean an individual or Legal Entity
24+
exercising permissions granted by this License.
25+
26+
"Source" form shall mean the preferred form for making modifications,
27+
including but not limited to software source code, documentation
28+
source, and configuration files.
29+
30+
"Object" form shall mean any form resulting from mechanical
31+
transformation or translation of a Source form, including but
32+
not limited to compiled object code, generated documentation,
33+
and conversions to other media types.
34+
35+
"Work" shall mean the work of authorship, whether in Source or
36+
Object form, made available under the License, as indicated by a
37+
copyright notice that is included in or attached to the work
38+
(an example is provided in the Appendix below).
39+
40+
"Derivative Works" shall mean any work, whether in Source or Object
41+
form, that is based on (or derived from) the Work and for which the
42+
editorial revisions, annotations, elaborations, or other modifications
43+
represent, as a whole, an original work of authorship. For the purposes
44+
of this License, Derivative Works shall not include works that remain
45+
separable from, or merely link (or bind by name) to the interfaces of,
46+
the Work and Derivative Works thereof.
47+
48+
"Contribution" shall mean any work of authorship, including
49+
the original version of the Work and any modifications or additions
50+
to that Work or Derivative Works thereof, that is intentionally
51+
submitted to Licensor for inclusion in the Work by the copyright owner
52+
or by an individual or Legal Entity authorized to submit on behalf of
53+
the copyright owner. For the purposes of this definition, "submitted"
54+
means any form of electronic, verbal, or written communication sent
55+
to the Licensor or its representatives, including but not limited to
56+
communication on electronic mailing lists, source code control systems,
57+
and issue tracking systems that are managed by, or on behalf of, the
58+
Licensor for the purpose of discussing and improving the Work, but
59+
excluding communication that is conspicuously marked or otherwise
60+
designated in writing by the copyright owner as "Not a Contribution."
61+
62+
"Contributor" shall mean Licensor and any individual or Legal Entity
63+
on behalf of whom a Contribution has been received by Licensor and
64+
subsequently incorporated within the Work.
65+
66+
2. Grant of Copyright License. Subject to the terms and conditions of
67+
this License, each Contributor hereby grants to You a perpetual,
68+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
69+
copyright license to reproduce, prepare Derivative Works of,
70+
publicly display, publicly perform, sublicense, and distribute the
71+
Work and such Derivative Works in Source or Object form.
72+
73+
3. Grant of Patent License. Subject to the terms and conditions of
74+
this License, each Contributor hereby grants to You a perpetual,
75+
worldwide, non-exclusive, no-charge, royalty-free, irrevocable
76+
(except as stated in this section) patent license to make, have made,
77+
use, offer to sell, sell, import, and otherwise transfer the Work,
78+
where such license applies only to those patent claims licensable
79+
by such Contributor that are necessarily infringed by their
80+
Contribution(s) alone or by combination of their Contribution(s)
81+
with the Work to which such Contribution(s) was submitted. If You
82+
institute patent litigation against any entity (including a
83+
cross-claim or counterclaim in a lawsuit) alleging that the Work
84+
or a Contribution incorporated within the Work constitutes direct
85+
or contributory patent infringement, then any patent licenses
86+
granted to You under this License for that Work shall terminate
87+
as of the date such litigation is filed.
88+
89+
4. Redistribution. You may reproduce and distribute copies of the
90+
Work or Derivative Works thereof in any medium, with or without
91+
modifications, and in Source or Object form, provided that You
92+
meet the following conditions:
93+
94+
(a) You must give any other recipients of the Work or
95+
Derivative Works a copy of this License; and
96+
97+
(b) You must cause any modified files to carry prominent notices
98+
stating that You changed the files; and
99+
100+
(c) You must retain, in the Source form of any Derivative Works
101+
that You distribute, all copyright, patent, trademark, and
102+
attribution notices from the Source form of the Work,
103+
excluding those notices that do not pertain to any part of
104+
the Derivative Works; and
105+
106+
(d) If the Work includes a "NOTICE" text file as part of its
107+
distribution, then any Derivative Works that You distribute must
108+
include a readable copy of the attribution notices contained
109+
within such NOTICE file, excluding those notices that do not
110+
pertain to any part of the Derivative Works, in at least one
111+
of the following places: within a NOTICE text file distributed
112+
as part of the Derivative Works; within the Source form or
113+
documentation, if provided along with the Derivative Works; or,
114+
within a display generated by the Derivative Works, if and
115+
wherever such third-party notices normally appear. The contents
116+
of the NOTICE file are for informational purposes only and
117+
do not modify the License. You may add Your own attribution
118+
notices within Derivative Works that You distribute, alongside
119+
or as an addendum to the NOTICE text from the Work, provided
120+
that such additional attribution notices cannot be construed
121+
as modifying the License.
122+
123+
You may add Your own copyright statement to Your modifications and
124+
may provide additional or different license terms and conditions
125+
for use, reproduction, or distribution of Your modifications, or
126+
for any such Derivative Works as a whole, provided Your use,
127+
reproduction, and distribution of the Work otherwise complies with
128+
the conditions stated in this License.
129+
130+
5. Submission of Contributions. Unless You explicitly state otherwise,
131+
any Contribution intentionally submitted for inclusion in the Work
132+
by You to the Licensor shall be under the terms and conditions of
133+
this License, without any additional terms or conditions.
134+
Notwithstanding the above, nothing herein shall supersede or modify
135+
the terms of any separate license agreement you may have executed
136+
with Licensor regarding such Contributions.
137+
138+
6. Trademarks. This License does not grant permission to use the trade
139+
names, trademarks, service marks, or product names of the Licensor,
140+
except as required for reasonable and customary use in describing the
141+
origin of the Work and reproducing the content of the NOTICE file.
142+
143+
7. Disclaimer of Warranty. Unless required by applicable law or
144+
agreed to in writing, Licensor provides the Work (and each
145+
Contributor provides its Contributions) on an "AS IS" BASIS,
146+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
147+
implied, including, without limitation, any warranties or conditions
148+
of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
149+
PARTICULAR PURPOSE. You are solely responsible for determining the
150+
appropriateness of using or redistributing the Work and assume any
151+
risks associated with Your exercise of permissions under this License.
152+
153+
8. Limitation of Liability. In no event and under no legal theory,
154+
whether in tort (including negligence), contract, or otherwise,
155+
unless required by applicable law (such as deliberate and grossly
156+
negligent acts) or agreed to in writing, shall any Contributor be
157+
liable to You for damages, including any direct, indirect, special,
158+
incidental, or consequential damages of any character arising as a
159+
result of this License or out of the use or inability to use the
160+
Work (including but not limited to damages for loss of goodwill,
161+
work stoppage, computer failure or malfunction, or any and all
162+
other commercial damages or losses), even if such Contributor
163+
has been advised of the possibility of such damages.
164+
165+
9. Accepting Warranty or Additional Liability. While redistributing
166+
the Work or Derivative Works thereof, You may choose to offer,
167+
and charge a fee for, acceptance of support, warranty, indemnity,
168+
or other liability obligations and/or rights consistent with this
169+
License. However, in accepting such obligations, You may act only
170+
on Your own behalf and on Your sole responsibility, not on behalf
171+
of any other Contributor, and only if You agree to indemnify,
172+
defend, and hold each Contributor harmless for any liability
173+
incurred by, or claims asserted against, such Contributor by reason
174+
of your accepting any such warranty or additional liability.
175+
176+
END OF TERMS AND CONDITIONS
177+
178+
APPENDIX: How to apply the Apache License to your work.
179+
180+
Copyright 2026 MCode Plugins contributors
181+
182+
Licensed under the Apache License, Version 2.0 (the "License");
183+
you may not use this file except in compliance with the License.
184+
You may obtain a copy of the License at
185+
186+
http://www.apache.org/licenses/LICENSE-2.0
187+
188+
Unless required by applicable law or agreed to in writing, software
189+
distributed under the License is distributed on an "AS IS" BASIS,
190+
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
191+
See the License for the specific language governing permissions and
192+
limitations under the License.

0 commit comments

Comments
 (0)