morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #1327] [Bug] npm latest (rea-agents@6.1.0) still ships the patterns fixed on main — strict-schema providers still reject every request #464

New issue

Closed

opened 2026-10-15 18:25:16 +00:00 by bsakaguchi · 3 comments

bsakaguchi commented

2026-10-15 18:25:16 +00:00

Owner

Originally created by @ljcyt on GitHub (Oct 9, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1327

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

MCP or agent integration

Summary

#1212 and #1282 were both closed as fixed on main (#1220, #1227, #1299). The fixes are correct — I verified each replacement against the same strict validator. But none of them are in a published release: npm dist-tags.latest is still rea-agents@6.1.0, published 2026-10-09T01:16Z, which predates all three.

So every npm/npx consumer — i.e. the documented install path — still ships the rejected patterns and still fails on every turn. This is a release gap, not a re-report of the underlying defect.

Observed behavior

Against a strict-schema OpenAI-compatible gateway, a client that loads the published tool list fails before any tool runs, on every turn. Two distinct error shapes, depending on the request path:

HTTP 503  {"error":{"message":"上游返回错误","type":"api_error","code":null}}

HTTP 400  {"code":11133,"msg":"Invalid request parameters",
           "extError":{"code":"model_param_invalid",
                       "message":"the request parameters were rejected by the model provider"}}

The 400/503 names no tool, and the client surfaces it as a generic turn failure. In my case the client retried 10 times over ~110 s and then aborted the turn; the session was unusable, and the error pointed at a tool I had never invoked.

Reproduction

Published artifact audit — a real stdio initialize + tools/list handshake against the npm release:

npx -y rea-agents@6.1.0 mcp

Result: 138 tools, 1976 pattern fields, of which 5 distinct patterns / 50 occurrences are rejected by a strict validator:

occurrences	pattern
44	`^[^\0]*$`
3	`^[^\s[\]]+$`
1	`^[^=\0]+$`
1	`^(?!/)(?!(?:.*/)?.{1,2}(?:/
1	`^(?!REA_PROCESS_RUN_ID(?![\s\S]))[^=\0]+$`

The npm tarball still carries the pre-fix source, e.g. dist/domain/native/nativeCallObservation.js:10:

.regex(/^[^\s[\]]+$/u, "Use the bare name without spaces or brackets");

whereas main src/domain/native/nativeCallObservation.ts:14 has:

.regex(/^[^\s\x5b\x5d]+$/u, "Use the bare name without spaces or brackets");

End-to-end, isolating the cause:

request	result
full tool list as published (257 tools)	503
drop the 138 rea tools, keep the other 119	200
keep only the 138 rea tools	503
keep all 257 tools, remove only the 5 patterns above	200

The last row is 731 KB of tool schemas and passes, so payload size is not a factor — the pattern content is the sole trigger. Removing any other single keyword ($schema, examples, additionalProperties, oneOf, const, …) changes nothing; removing pattern alone fixes it.

Expected behavior

npm i rea-agents / npx -y rea-agents@<latest> mcp should install a build whose advertised pattern values compile under the strict validators already handled on main, so a strict-schema provider accepts the tool list and the session is usable.

Verification that the fix on `main` is sufficient

Each replacement is accepted by the same validator that rejects the published form, tested in isolation:

npm 6.1.0	strict validator	`main` replacement	strict validator
`^[^\0]*$`	REJECT	`^[^\u0000]*$`	OK
`^[^=\0]+$`	REJECT	`^[^=\u0000]+$`	OK
`^[^\s[\]]+$`	REJECT	`^[^\s\x5b\x5d]+$`	OK
(look-around form)	REJECT	`^(?!REA_PROCESS_RUN_ID$)[^=]+$`	OK

\x00 and \^@ spellings also pass. So no further code change is needed — only a publish.

Impact and scope

Affected: anyone consuming the npm package (the default install path), on any provider whose tool-schema validator is strict.
Not affected: running from main, or a build produced from main — the issue is purely the published artifact lagging the fix.
Severity: the failure is total and non-recoverable from inside the session, since tool schemas ride on every request. The user cannot even ask the client to help diagnose it.
No impact on evidence integrity or process isolation.

Workaround

A ~90-line stdio shim between the client and the server that rewrites only the tools/list response (drops the 5 patterns above, passes every other byte through unchanged). Measured: 50 rejected patterns → 0, tool count unchanged at 138, and all requests in the table above return 200.

Ask

Please cut a patch release (e.g. 6.1.1) from main so npm consumers pick up #1220 / #1227 / #1299. Happy to re-run this audit against a prerelease or a next tag and report back.

Originally created by @ljcyt on GitHub (Oct 9, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1327 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area MCP or agent integration ### Summary #1212 and #1282 were both closed as fixed on `main` (#1220, #1227, #1299). The fixes are correct — I verified each replacement against the same strict validator. But **none of them are in a published release**: npm `dist-tags.latest` is still `rea-agents@6.1.0`, published 2026-10-09T01:16Z, which predates all three. So every npm/npx consumer — i.e. the documented install path — still ships the rejected patterns and still fails on every turn. This is a release gap, not a re-report of the underlying defect. ### Observed behavior Against a strict-schema OpenAI-compatible gateway, a client that loads the published tool list fails before any tool runs, on **every** turn. Two distinct error shapes, depending on the request path: ```text HTTP 503 {"error":{"message":"上游返回错误","type":"api_error","code":null}} ``` ```text HTTP 400 {"code":11133,"msg":"Invalid request parameters", "extError":{"code":"model_param_invalid", "message":"the request parameters were rejected by the model provider"}} ``` The 400/503 names no tool, and the client surfaces it as a generic turn failure. In my case the client retried 10 times over ~110 s and then aborted the turn; the session was unusable, and the error pointed at a tool I had never invoked. ### Reproduction Published artifact audit — a real stdio `initialize` + `tools/list` handshake against the npm release: ```bash npx -y rea-agents@6.1.0 mcp ``` Result: **138 tools, 1976 `pattern` fields, of which 5 distinct patterns / 50 occurrences are rejected** by a strict validator: | occurrences | pattern | | --- | --- | | 44 | `^[^\0]*$` | | 3 | `^[^\s[\]]+$` | | 1 | `^[^=\0]+$` | | 1 | `^(?!\/)(?!(?:.*\/)?\.{1,2}(?:\/|$))(?!.*\/\/)(?!.*\/$)[^\\\0]+$` | | 1 | `^(?!REA_PROCESS_RUN_ID(?![\s\S]))[^=\0]+$` | The npm tarball still carries the pre-fix source, e.g. `dist/domain/native/nativeCallObservation.js:10`: ```js .regex(/^[^\s[\]]+$/u, "Use the bare name without spaces or brackets"); ``` whereas `main` `src/domain/native/nativeCallObservation.ts:14` has: ```ts .regex(/^[^\s\x5b\x5d]+$/u, "Use the bare name without spaces or brackets"); ``` End-to-end, isolating the cause: | request | result | | --- | --- | | full tool list as published (257 tools) | **503** | | drop the 138 rea tools, keep the other 119 | **200** | | keep only the 138 rea tools | **503** | | keep all 257 tools, remove only the 5 patterns above | **200** | The last row is 731 KB of tool schemas and passes, so payload size is not a factor — the pattern content is the sole trigger. Removing any other single keyword (`$schema`, `examples`, `additionalProperties`, `oneOf`, `const`, …) changes nothing; removing `pattern` alone fixes it. ### Expected behavior `npm i rea-agents` / `npx -y rea-agents@<latest> mcp` should install a build whose advertised `pattern` values compile under the strict validators already handled on `main`, so a strict-schema provider accepts the tool list and the session is usable. ### Verification that the fix on `main` is sufficient Each replacement is accepted by the same validator that rejects the published form, tested in isolation: | npm 6.1.0 | strict validator | `main` replacement | strict validator | | --- | --- | --- | --- | | `^[^\0]*$` | REJECT | `^[^\u0000]*$` | OK | | `^[^=\0]+$` | REJECT | `^[^=\u0000]+$` | OK | | `^[^\s[\]]+$` | REJECT | `^[^\s\x5b\x5d]+$` | OK | | (look-around form) | REJECT | `^(?!REA_PROCESS_RUN_ID$)[^=]+$` | OK | `\x00` and `\^@` spellings also pass. So no further code change is needed — only a publish. ### Impact and scope - Affected: anyone consuming the npm package (the default install path), on any provider whose tool-schema validator is strict. - Not affected: running from `main`, or a build produced from `main` — the issue is purely the published artifact lagging the fix. - Severity: the failure is total and non-recoverable from inside the session, since tool schemas ride on every request. The user cannot even ask the client to help diagnose it. - No impact on evidence integrity or process isolation. ### Workaround A ~90-line stdio shim between the client and the server that rewrites only the `tools/list` response (drops the 5 patterns above, passes every other byte through unchanged). Measured: 50 rejected patterns → 0, tool count unchanged at 138, and all requests in the table above return 200. ### Ask Please cut a patch release (e.g. `6.1.1`) from `main` so npm consumers pick up #1220 / #1227 / #1299. Happy to re-run this audit against a prerelease or a `next` tag and report back.

bsakaguchi

2026-10-15 18:25:16 +00:00

closed this issue
added the
area: mcp

bug
labels

bsakaguchi commented

2026-10-15 18:25:17 +00:00

Author

Owner

@CassieFox23 commented on GitHub (Oct 9, 2026):

TL;DR: I ran the same count. 6.1.0 shows your 50 bad patterns exactly. 6.2.0 has none of them.

Checked the published rea-agents@6.2.0 (now npm latest) with the same stdio initialize + tools/list handshake. I counted every pattern field in the advertised tool schemas.

	6.1.0	6.2.0
tools	138	139
`pattern` fields	1976	864
the 5 rejected patterns in the table above	50 (44 / 3 / 1 / 1 / 1)	0

6.1.0 gives exactly your counts, so the method matches yours. In 6.2.0's tool list no pattern contains \0, a lookahead, or the unescaped [/] class either.

I only checked the advertised schemas. Not a request against a strict-schema gateway.

Test setup

Box: Linux x86-64
Node: 22.22.2

🤖 Generated with Claude Code (Opus 5.5) 🦊

@CassieFox23 commented on GitHub (Oct 9, 2026): **TL;DR:** I ran the same count. 6.1.0 shows your 50 bad patterns exactly. 6.2.0 has none of them. Checked the published `rea-agents@6.2.0` (now npm `latest`) with the same stdio `initialize` + `tools/list` handshake. I counted every `pattern` field in the advertised tool schemas. | | 6.1.0 | 6.2.0 | | --- | --- | --- | | tools | 138 | 139 | | `pattern` fields | 1976 | 864 | | the 5 rejected patterns in the table above | 50 (44 / 3 / 1 / 1 / 1) | 0 | 6.1.0 gives exactly your counts, so the method matches yours. In 6.2.0's tool list no `pattern` contains `\0`, a lookahead, or the unescaped `[`/`]` class either. I only checked the advertised schemas. Not a request against a strict-schema gateway. <details> <summary>Test setup</summary> - Box: Linux x86-64 - Node: 22.22.2 </details> 🤖 Generated with Claude Code (Opus 5.5) 🦊

bsakaguchi commented

2026-10-15 18:25:17 +00:00

Author

Owner

@N0zoM1z0 commented on GitHub (Oct 9, 2026):

rea-agents@6.2.0 is now published as npm latest, with the fixes from #1220, #1227 and #1299. Release: https://github.com/morluto/rea/releases/tag/rea-agents-6.2.0

We verified the public npm artifact through a real stdio MCP handshake (139 tools) and the packaged CLI/update canary. Your follow-up independently confirms zero occurrences of the five rejected patterns in 6.2.0. Actual acceptance by your gateway remains outside our verification.

Closing the published-artifact gap. Upgrade to 6.2.0 and restart the MCP client so it reloads the tool schemas.

@N0zoM1z0 commented on GitHub (Oct 9, 2026): `rea-agents@6.2.0` is now published as npm `latest`, with the fixes from #1220, #1227 and #1299. Release: https://github.com/morluto/rea/releases/tag/rea-agents-6.2.0 We verified the public npm artifact through a real stdio MCP handshake (139 tools) and the packaged CLI/update canary. Your follow-up independently confirms zero occurrences of the five rejected patterns in 6.2.0. Actual acceptance by your gateway remains outside our verification. Closing the published-artifact gap. Upgrade to 6.2.0 and restart the MCP client so it reloads the tool schemas.

bsakaguchi commented

2026-10-15 18:25:17 +00:00

Author

Owner

@ljcyt commented on GitHub (Oct 10, 2026):

Verified 6.2.0 against the actual strict-schema gateway — the step noted as outside your verification scope.

Method: real stdio initialize + tools/list against npx -y rea-agents@6.2.0 mcp, then the advertised tools converted to the provider's tool format (inputSchema → parameters) and sent verbatim in a live request. No pattern was edited by me; 6.2.0's schemas went through untouched.

Published artifact audit

	6.1.0	6.2.0
tools	138	139
`pattern` fields	1976	864
rejected by strict validator	50 (5 distinct)	0

Gateway acceptance (the previously unverified step)

request	6.1.0	6.2.0
rea tools only (138 / 139)	`503 上游返回错误`	200
rea tools + 119 non-rea tools (257 / 258)	`503`	200
same tools on the `/responses` path	`503`	200

6.2.0 returns a normal completion on all three; 6.1.0 returns 503 on all three, on the same provider, same minute, same key. So the gateway does accept 6.2.0's schemas — the fix is effective end-to-end, not just under a local regex compile.

One note for anyone re-running this: MCP advertises inputSchema, and a tool entry that forwards parameters instead (leaving it empty) is itself rejected by this gateway with the same 503. That cost me one wrong intermediate reading — worth watching for if you extend the catalog-wide assertion to a live request.

Thanks for the fast turnaround on the release; issue closed on my side.

@ljcyt commented on GitHub (Oct 10, 2026): Verified 6.2.0 against the actual strict-schema gateway — the step noted as outside your verification scope. **Method:** real stdio `initialize` + `tools/list` against `npx -y rea-agents@6.2.0 mcp`, then the advertised tools converted to the provider's tool format (`inputSchema` → `parameters`) and sent verbatim in a live request. No pattern was edited by me; 6.2.0's schemas went through untouched. **Published artifact audit** | | 6.1.0 | 6.2.0 | | --- | --- | --- | | tools | 138 | 139 | | `pattern` fields | 1976 | 864 | | rejected by strict validator | 50 (5 distinct) | **0** | **Gateway acceptance (the previously unverified step)** | request | 6.1.0 | 6.2.0 | | --- | --- | --- | | rea tools only (138 / 139) | `503 上游返回错误` | **200** | | rea tools + 119 non-rea tools (257 / 258) | `503` | **200** | | same tools on the `/responses` path | `503` | **200** | 6.2.0 returns a normal completion on all three; 6.1.0 returns 503 on all three, on the same provider, same minute, same key. So the gateway does accept 6.2.0's schemas — the fix is effective end-to-end, not just under a local regex compile. One note for anyone re-running this: MCP advertises `inputSchema`, and a tool entry that forwards `parameters` instead (leaving it empty) is itself rejected by this gateway with the same `503`. That cost me one wrong intermediate reading — worth watching for if you extend the catalog-wide assertion to a live request. Thanks for the fast turnaround on the release; issue closed on my side.

bsakaguchi referenced this issue

2026-10-15 18:28:29 +00:00

[GH-ISSUE #2383] [Tracker] Audit analysis and debugging coverage for the TIOBE top 100 languages (October 2026) #794

bsakaguchi referenced this issue

2026-10-16 21:13:22 +00:00

[PR #464] [MERGED] feat(electron): add autonomous Electron runtime analysis #2012