VS Code Messenger Developer ToolVisualizes message traffic — requests, responses, and notifications — between a VS Code extension host and its registered webviews for extensions that use the vscode-messenger library. It is the fastest way to answer "is the message actually being sent?", "did the receiver get it?", and "what does the payload look like?" while developing or debugging. Open the devtool viewOpen the Command Palette ( The devtool lists every installed extension that depends on
Exposing the diagnostic API from your extensionThe devtool reads from the public API your
If your extension already exports a public API, spread the diagnostic methods into it:
The devtool checks
|
| Option | Default | Effect |
|---|---|---|
withParameterData |
false |
Includes request/notification params as MessengerEvent.parameter in every event. |
withResponseData |
false |
Includes response result as MessengerEvent.parameter on type: 'response' events. |
Enable both during development to see full payload values in the event details panel:
return messenger.diagnosticApi({ withParameterData: true, withResponseData: true });
What the devtool shows
The devtool calls extensionInfo() to populate the overview panel:
- webviews — registered webview instances (
{ id, type }) - handlers — registered message handlers (
{ method, count }) - pendingRequest — count of in-flight requests
- diagnosticListeners — count of active event subscribers
It also subscribes via addEventListener to receive a MessengerEvent for every message that passes through the host-side Messenger:
| Field | Description |
|---|---|
type |
'request', 'response', 'notification', or 'unknown' |
id? |
Request id — set for requests and their matching responses |
method? |
Message method name (absent on response events — correlate by id) |
sender, receiver |
Stringified participants: 'host extension', webviewId, webviewType, or 'broadcast' |
parameter? |
Payload — only populated when withParameterData / withResponseData is enabled |
error? |
Error message for failed responses |
size |
Serialized payload byte-size estimate |
timestamp |
Date.now() at the moment the event was emitted |
Customizing events before they reach the devtool
You can wrap addEventListener to mutate events before any listener — including the devtool — sees them. A useful pattern is to decorate method names with their parameter values so the event timeline is easier to read:
export function activate(context: vscode.ExtensionContext): MessengerDiagnostic {
// Your activation code...
const diagnostics = messenger.diagnosticApi({
withParameterData: true,
withResponseData: true
});
return {
...diagnostics,
addEventListener: (listener) => diagnostics.addEventListener(event => {
if (event.method === 'colorSelected') {
event.method = `colorSelected(${JSON.stringify(event.parameter)})`;
}
listener(event);
})
};
}
The wrapper must still satisfy isMessengerDiagnostic — keep the original extensionInfo and removeEventListener on the returned object (the spread above handles this).
Troubleshooting
No row for my extension in the devtool
The devtool detected that your extension depends on vscode-messenger but activate either threw, returned undefined, or returned something where isMessengerDiagnostic is false. Confirm that activate returns the diagnostic object (or a spread that includes its three methods: extensionInfo, addEventListener, removeEventListener).
Extension is listed, but no events appear
activate returned the diagnostic API, but no traffic has been produced yet — trigger a message. Note that the host-side Messenger only observes host-side traffic; webview-internal processing does not produce events until a message is posted back to the host.
Events appear but parameter is always empty
withParameterData and withResponseData are both false by default. Pass { withParameterData: true, withResponseData: true } to diagnosticApi in your dev build.
Events visible for one webview only
The diagnostic API observes only the Messenger instance you exposed. If your extension creates multiple Messenger instances (uncommon), each needs its own diagnostic export.
