[GH-ISSUE #8775] [Bug] Ghidra regex errors do not identify the pattern field #7540

New issue

Closed

opened 2026-11-03 11:23:23 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-11-03 11:23:23 +00:00

Owner

Originally created by @morluto on GitHub (Nov 3, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/8775

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

Observed behavior

Real Ghidra-backed search_procedures and search_strings reject an invalid regex, but the structured input issue identifies the entire request (path: []) instead of pattern. The top-level message is generic, so an agent must inspect the nested diagnostic text to discover what to correct. Real Kuna returns path: ["pattern"] and reason: "invalid_format" for the same input.

Reproduction

On REA 9ebbe67e05af08b567e215340da993c08dae378f, open a self-built Mach-O in the public stdio MCP session using Ghidra 12.1.4. Invoke each tool with {"pattern":"[","mode":"regex","detail":"complete"}. Both return invalid_request, with an issue like:

{"path":[],"reason":"invalid_value","message":"Invalid regex pattern [: Unclosed character class at index 0"}

Repeat with pattern: "shared_func", mode: "literal" and then pattern: "shared_func$", mode: "regex": both searches succeed in the same session. The procedure search returns both matching functions. The string controls succeeded but are not claimed to contain matches. The same invalid requests with Kuna 1.989 identify pattern as invalid_format; subsequent corrected requests succeed.

Expected behavior

Identify pattern as the invalid field and preserve the provider's actual regex syntax explanation. Keep the provider's dialect distinct: Ghidra and Kuna need not accept identical patterns. Do not classify unrelated generic provider failures as regex failures based on message text.

Impact and scope

An agent can manually recover from the nested explanation; field-oriented clients cannot identify the bad argument from the Ghidra issue path. Both search operations and the compact MCP output profile were exercised on one fixture; full profile and CLI behavior are unverified. No claim is made about all invalid regexes or other providers.

REA version

9ebbe67e05af08b567e215340da993c08dae378f.

Runtime and platform

macOS arm64, Node 24.22.1, Ghidra 12.1.4/JDK 21, Kuna 1.989.

Target and artifact context

Self-built, unexecuted Mach-O; SHA-256 ae0f2a349b22332113ab60ab4c78024eb18153c76bdeefb01c4b1d89a26c0003, unchanged across each control.

Interface

MCP

Earliest failure stage

Transport or result projection (source-derived hypothesis; the bridge currently reports a generic invalid_request).

Relevant output or evidence

The exact structured issue and corrected-call results are above. Local fixture and test harness are disposable and not attached.

Typed outcome or recovery expected

Return invalid_request with a pattern / invalid_format issue and the specific parser message, while keeping request-scoped failure and a usable session.

Analysis or suspected cause

Ghidra's generic invalid_request currently reaches the shared projection without typed field attribution. Confirm the bridge's producing boundary and downstream callers before changing it; do not infer identity from error prose.

Additional context

Related closed reports #5986 and #6107 addressed missing pattern diagnostics for Hopper and Kuna respectively.

@gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

Originally created by @morluto on GitHub (Nov 3, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/8775 ### 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 ### Observed behavior Real Ghidra-backed `search_procedures` and `search_strings` reject an invalid regex, but the structured input issue identifies the entire request (`path: []`) instead of `pattern`. The top-level message is generic, so an agent must inspect the nested diagnostic text to discover what to correct. Real Kuna returns `path: ["pattern"]` and `reason: "invalid_format"` for the same input. ### Reproduction On REA `9ebbe67e05af08b567e215340da993c08dae378f`, open a self-built Mach-O in the public stdio MCP session using Ghidra 12.1.4. Invoke each tool with `{"pattern":"[","mode":"regex","detail":"complete"}`. Both return `invalid_request`, with an issue like: ```json {"path":[],"reason":"invalid_value","message":"Invalid regex pattern [: Unclosed character class at index 0"} ``` Repeat with `pattern: "shared_func", mode: "literal"` and then `pattern: "shared_func$", mode: "regex"`: both searches succeed in the same session. The procedure search returns both matching functions. The string controls succeeded but are not claimed to contain matches. The same invalid requests with Kuna 1.989 identify `pattern` as `invalid_format`; subsequent corrected requests succeed. ### Expected behavior Identify `pattern` as the invalid field and preserve the provider's actual regex syntax explanation. Keep the provider's dialect distinct: Ghidra and Kuna need not accept identical patterns. Do not classify unrelated generic provider failures as regex failures based on message text. ### Impact and scope An agent can manually recover from the nested explanation; field-oriented clients cannot identify the bad argument from the Ghidra issue path. Both search operations and the compact MCP output profile were exercised on one fixture; full profile and CLI behavior are unverified. No claim is made about all invalid regexes or other providers. ### REA version `9ebbe67e05af08b567e215340da993c08dae378f`. ### Runtime and platform macOS arm64, Node 24.22.1, Ghidra 12.1.4/JDK 21, Kuna 1.989. ### Target and artifact context Self-built, unexecuted Mach-O; SHA-256 `ae0f2a349b22332113ab60ab4c78024eb18153c76bdeefb01c4b1d89a26c0003`, unchanged across each control. ### Interface MCP ### Earliest failure stage Transport or result projection (source-derived hypothesis; the bridge currently reports a generic `invalid_request`). ### Relevant output or evidence The exact structured issue and corrected-call results are above. Local fixture and test harness are disposable and not attached. ### Typed outcome or recovery expected Return `invalid_request` with a `pattern` / `invalid_format` issue and the specific parser message, while keeping request-scoped failure and a usable session. ### Analysis or suspected cause Ghidra's generic `invalid_request` currently reaches the shared projection without typed field attribution. Confirm the bridge's producing boundary and downstream callers before changing it; do not infer identity from error prose. ### Additional context Related closed reports #5986 and #6107 addressed missing pattern diagnostics for Hopper and Kuna respectively. @gensokyo-dev @kaoru0822-kitauji @N0zoM1z0

bsakaguchi added the

bug

triage

labels

2026-11-03 11:23:23 +00:00

bsakaguchi commented

2026-11-03 22:45:05 +00:00

Author

Owner

@r727215164-bit commented on GitHub (Nov 3, 2026):

https://www.instagram.com/0_s__hi__z__u_0?xtok=dzY0cmFpcXh5ZGI1

@r727215164-bit commented on GitHub (Nov 3, 2026): https://www.instagram.com/0_s__hi__z__u_0?xtok=dzY0cmFpcXh5ZGI1