fix(telemetry): propagate remote flag to per-tool events

[wonderwhy-er]

Problem

Remote tool calls are a telemetry blind spot for content detail. We can see that a remote user called start_process (via server_call_tool with remote=true), but not what file types they read/wrote or what commands they ran.

Investigating BigQuery, every detailed per-tool event — server_start_process (carries command/commands), server_read_file/server_write_file/server_edit_block (carry fileExtension/fileSize) — is recorded as remote=not_set, even for calls that clearly came from a remote device. Confirmed: 0 of these events across late May carry remote=true.

Root cause

In the CallTool handler (server.ts), _meta.clientInfo and _meta.remote were handled asymmetrically:

• clientInfo → persisted to the module-level currentClient via updateCurrentClient(), which buildEventProperties (in capture.ts) reads for every event. So client attribution "leaks" correctly to all downstream events.
• remote → written only to the local telemetryData object passed to the single capture_call_tool('server_call_tool', ...) call. It was never persisted anywhere the tool handlers' own capture() calls could see it.

So when improved-process-tools.ts, filesystem.ts, edit.ts etc. fire their detailed capture('server_start_process', { command, commands }) events, there's no remote context available → remote=not_set.

Fix

Mirror the existing currentClient pattern:

1. Add a module-level currentCallIsRemote flag + setCurrentCallIsRemote() setter in server.ts, exported alongside currentClient.
2. The CallTool handler sets it on every call — true when _meta.remote is present, false otherwise. The explicit reset-to-false guard prevents a remote call from leaking its flag onto a subsequent local call.
3. buildEventProperties (proxy/BigQuery path) and captureBase (legacy GA4 path) both stamp remote: "true" onto every event when currentCallIsRemote is set. Placed before the caller's sanitizedProperties spread so an explicit remote (e.g. from captureRemote) still wins.

After this lands, server_start_process / server_read_file / etc. from remote clients will carry remote=true, giving us file-type and command visibility for remote usage at parity with local.

Notes / caveat for reviewers

• This relies on ES module live bindings — the same mechanism currentClient already uses (it's reassigned in updateCurrentClient and read live by capture.ts). The circular import capture.ts ↔ server.ts already exists for currentClient; this adds nothing new.
• Known limitation (pre-existing): like currentClient, this is module-level mutable state, so it assumes one logical call in flight at a time. If local and remote calls interleave concurrently, attribution could be momentarily wrong. The fully-correct solution is request-scoped context (AsyncLocalStorage), but that's a larger refactor; this change reaches parity with the existing accepted behavior and fixes the vast majority of real cases (users typically run one client at a time).

Testing

• npx tsc --noEmit — clean (exit 0)
• npm run build — succeeds; verified currentCallIsRemote present in compiled dist/server.js and dist/utils/capture.js

Summary by CodeRabbit

• Improvements
  • Enhanced telemetry capabilities to differentiate and track tool calls originating from remote versus local devices, enabling better diagnostics and usage insights.

[coderabbitai]

📝 Walkthrough

Walkthrough

The PR adds remote call tracking to the server layer and propagates this information to telemetry capture. A new currentCallIsRemote flag is defined, set based on request metadata during tool call handling, and automatically injected into event properties to attribute telemetry to remote or local call origins.

Changes

Remote Call Attribution in Telemetry

Layer / File(s)	Summary
Remote call state tracking src/server.ts	Module-level currentCallIsRemote boolean flag and setCurrentCallIsRemote() helper are introduced to track whether the current tool call originated from a remote device; the flag is exported for use by other modules.
Remote flag detection in request handler src/server.ts	The CallToolRequestSchema handler extracts isRemoteCall from request metadata and resets currentCallIsRemote at the start of each call to prevent remote attribution leakage across calls.
Telemetry attribution based on call origin src/utils/capture.ts	currentCallIsRemote is imported and conditionally injected as remote: "true" into event properties in both captureBase and buildEventProperties, positioned before sanitized properties to allow caller override.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

• wonderwhy-er/DesktopCommanderMCP#349: Both PRs modify event-property construction in src/utils/capture.ts to alter telemetry payloads during event capture.
• wonderwhy-er/DesktopCommanderMCP#176: Both PRs inject metadata into event properties within src/utils/capture.ts to contextualize telemetry based on execution environment.
• wonderwhy-er/DesktopCommanderMCP#153: Both PRs modify CallToolRequestSchema handling in src/server.ts and integrate changes into the shared event-capture flow in src/utils/capture.ts.

Suggested labels

size:L

Poem

🐰 A flag for the remote, a path crystal clear,
Set once per call, no state to fear,
Telemetry whispers which origin rings—
Local or distant, the metadata brings! 📡✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main change: propagating a remote flag to telemetry events for individual tool calls, which is the core purpose of this PR.
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/remote-flag-telemetry-propagation

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/server.ts`:
- Around line 1199-1203: The module-level flag currentCallIsRemote (and setter
setCurrentCallIsRemote) causes race conditions; instead carry isRemoteCall in
request-local context: stop calling setCurrentCallIsRemote here, attach
isRemoteCall to the request/metadata object or store it in an AsyncLocalStorage
context created per capture()/CallTool invocation, then update consumers (the
GA4 path and proxy path that currently read currentCallIsRemote) to read the
request-local value (e.g., metadata.isRemoteCall or
asyncLocal.getStore().isRemoteCall) so each tool invocation has its own isolated
remote flag.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 1b06352f-8a6d-42f8-b95e-5b7e000ad0db

📥 Commits

Reviewing files that changed from the base of the PR and between 9c44119 and 97a61bc.

📒 Files selected for processing (2)

• src/server.ts
• src/utils/capture.ts

[coderabbitai]

⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Don't use a shared module flag for request-scoped telemetry state.

currentCallIsRemote can be overwritten by another CallTool while this handler is still awaiting config/tool work, so nested capture() calls will sometimes stamp the wrong remote value. Because the GA4 and proxy paths read this flag later and independently, the two events can even disagree for the same tool call. Please carry isRemoteCall in request-local context instead of module state.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/server.ts` around lines 1199 - 1203, The module-level flag
currentCallIsRemote (and setter setCurrentCallIsRemote) causes race conditions;
instead carry isRemoteCall in request-local context: stop calling
setCurrentCallIsRemote here, attach isRemoteCall to the request/metadata object
or store it in an AsyncLocalStorage context created per capture()/CallTool
invocation, then update consumers (the GA4 path and proxy path that currently
read currentCallIsRemote) to read the request-local value (e.g.,
metadata.isRemoteCall or asyncLocal.getStore().isRemoteCall) so each tool
invocation has its own isolated remote flag.

[edgarsskore]

loooks good