You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
PostMessageTransport: make debug logging opt-in (or accept a logger) #786
PostMessageTransport calls console.debug unconditionally (src/message-transport.ts at 264d9ca, lines 77, 82, 87 and 128):
"Sending message" for every outgoing message except tool-input-partial
"Parsed message" for every valid incoming message
"Ignoring message from unknown source" for every message from another frame
A host cannot turn these off. The transport takes no option for it, and the only workaround is wrapping console.debug globally.
The noise grows with the number of Apps on a page. Each card's host transport listens on the same window, so a message from any View reaches every bridge. The owning bridge logs "Parsed message", and each of the other N−1 bridges logs "Ignoring message from unknown source" with the full MessageEvent. With four cards in a conversation, every View message produces four host lines, plus the View's own "Sending message" inside its frame. Size changes and host-context updates fan out the same way.
The source check is correct. Only the logging is the problem.
Log nothing when logger is absent. The console.error for a malformed JSON-RPC message can stay. The third argument keeps the existing constructor compatible.
Proposed scope: make PostMessageTransport debug diagnostics opt-in via an optional third constructor argument ({ logger?: Pick<Console, 'debug'> }), keep existing constructor calls backward compatible, preserve console.error for malformed JSON-RPC messages, and add regression tests covering silent-by-default behavior and explicit logging. I have a local patch prepared and will run the repository checks before opening a PR.
Please let me know if you would prefer a different API shape.
Activity
gabrieledellamalva commentedon Oct 9, 2026
I'd like to contribute a focused fix for this.
Proposed scope: make
PostMessageTransportdebug diagnostics opt-in via an optional third constructor argument ({ logger?: Pick<Console, 'debug'> }), keep existing constructor calls backward compatible, preserveconsole.errorfor malformed JSON-RPC messages, and add regression tests covering silent-by-default behavior and explicit logging. I have a local patch prepared and will run the repository checks before opening a PR.Please let me know if you would prefer a different API shape.