* fix(irc): chunk PRIVMSG by UTF-8 byte budget so long non-ASCII messages are not truncated
IRC caps a full protocol line at 512 bytes, but sendPrivmsg split outbound
text by UTF-16 code units against the 350 char default. Multi-byte text such
as CJK or emoji produced lines far beyond 512 bytes and servers silently
dropped the tail of every oversized chunk. The chunker now also enforces a
UTF-8 byte budget derived from the line framing overhead, splitting on code
point boundaries and preferring spaces, while ASCII chunking is unchanged.
* test(irc): move loopback IRC server helper to shared test helpers
The colocated node:net import tripped the network-runtime-boundary PR diff
scan for extensions/irc/src. The loopback server now lives in test/helpers,
outside the scanned network runtime paths, and the CJK, emoji, and ASCII
chunking cases keep driving the real client over a real TCP socket.
* fix(irc): decouple byte budget from character cap and move loopback helper to irc test-support
The byte budget is now derived only from the 512-byte line limit and framing
overhead, independent of messageChunkMaxChars, so low character caps with
multibyte text keep advancing instead of dropping the message. The loopback
IRC server helper moves from test/helpers to the extension-local package-root
test-support surface so extension tests stay off repo helper bridges and raw
socket use stays outside extensions/irc/src.
* fix(irc): enforce UTF-8 wire limits
* test(irc): satisfy loopback harness lint
* test(irc): avoid implicit Promise return
* test(irc): handle loopback close errors
* fix(irc): preserve boundary word splitting
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(agents): prevent ReDoS in MCP glob-to-regex wildcard matching
Collapse consecutive '*' wildcards into a single '*' before building
the regex in globMatches(). Without this, a glob like '**********-x'
tested against a non-matching string causes catastrophic backtracking
(238s for a single call with 10 stars vs 0.4ms after fix).
Affected functions:
- src/agents/agent-bundle-mcp-runtime.ts: globMatches (MCP tool name filter)
- src/agents/agent-bundle-mcp-materialize.ts: globMatches (MCP operation filter)
Co-Authored-By: Claude <noreply@anthropic.com>
* fix(agents): make MCP filter matching linear
* style(mcp): satisfy filter lint
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(browser): resolve act targetId aliases before mismatch check
The /act top-level and batch targetId guards compared the caller-supplied
targetId against the resolved canonical tab.targetId with raw string
equality. Any supported alias form (tabId, label, suggestedTargetId, or a
unique id prefix) resolves to a different canonical id, so act requests that
followed the documented 'prefer suggestedTargetId/tabId/label' guidance were
rejected with 403 ACT_TARGET_ID_MISMATCH even though they named the correct
tab. snapshot/open/close/tabs lack this guard and kept working, matching the
reported symptom matrix.
Resolve the action targetId through the same tab alias resolution the route
used and reject only ids that resolve to a different tab.
* fix(browser): canonicalize act targetId aliases before Playwright dispatch
The /act gate accepted tabId/label/suggested/prefix aliases of the request
tab but left them on action.targetId. The managed executor reads
action.targetId ?? targetId for an exact page lookup (executeSingleAction ->
getPageForTargetId), so an alias missed the lookup and broke the action at
runtime whenever more than one page was open (single-page masked it via the
pages.length===1 fallback). Canonicalize the action targetId (top-level and
nested batch sub-actions) to the resolved tab id before dispatch; reject ids
that resolve to a different tab. Replace the mock-masked contract assertions
with executor-action assertions plus direct canonicalizer unit tests.
* test(browser): brace act-targetId guard clauses for curly lint
* docs(changelog): note browser target alias fix
* docs(changelog): note browser target alias fix
* fix(browser): reject ambiguous batch target aliases
* test(browser): type targetless act fixture
* docs(changelog): move browser alias fix to unreleased
* chore: drop nonessential browser changelog entry
---------
Co-authored-by: Peter Steinberger <peter@steipete.me>
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(cron): preserve delivery thread id type across SQLite reload
A numeric delivery threadId such as a Telegram forum topic id reloaded as
a string after a gateway restart because the split delivery_thread_id
column stores TEXT. resolveCronDeliveryPlan and channel delivery are type
sensitive, so the numeric topic id was forwarded as a string and dropped
the configured topic.
Source the delivery threadId type from the canonical job_json config on
read, falling back to the raw column text. Both freshly written rows and
legacy bare-text rows keep string versus number identity without any
column format change or migration.
* fix(cron): recover typed delivery thread id when split column is null
* fix(cron): persist delivery thread ID type
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
* fix(agents): surface real plugin approval rejection reason to agent
Distinguish gateway-rejection errors from transport failures in the
plugin approval catch block. When the error is a GatewayClientRequestError
(with a structured gatewayCode), the gateway is reachable and actively
rejected the request — surface the real rejection reason. Otherwise keep
the existing "gateway unavailable" message for genuine transport failures.
Previously every approval gateway error was reported as "gateway
unavailable", even when the gateway was healthy and returned a
structured rejection like INVALID_REQUEST. This misdirected operators
and agents toward connectivity debugging instead of the actual schema
or policy violation.
Fixes#100212
* fix(agents): report plugin approval rejections accurately
Co-authored-by: 唐梓夷0668001293 <tang.ziyi@xydigit.com>
---------
Co-authored-by: Peter Steinberger <steipete@gmail.com>
