OpenTelemetry Export Wire Reference

Companion to OpenTelemetry Export. This page lists every metric, log event, attribute, enum value, and presence rule Cursor exports.

Cursor adds new attributes, events, and enum values over time without a version bump. Build your pipeline to ignore values it doesn't recognize rather than reject the record. Cursor gives explicit notice before it renames or removes anything.

How to read the tables:

• Presence says when an attribute appears. Always is on every record of the event. Optional isn't on every record, so your pipeline shouldn't require it. The notes say when it appears, where that's defined.
• (open) marks a value that isn't drawn from a fixed list, such as a customer-defined name.
• Bot means a Grok Bot. Its computer (box in attribute names) is the Grok Bot computer the Bot works on. A card is the approval card a person answers.

Transport and scope

• OTLP/HTTP binary protobuf (application/x-protobuf), POST
• Endpoints: <base>/v1/metrics and <base>/v1/logs
• Scope: cursor.telemetry / 0.1.0

Resource attributes

One resource per (team, user, surface, entrypoint, surface version, Project) grouping.

Families

Family ids match the toggles in Team Settings. Every family is on by default for a new destination except conversation_content. That family stays off until the team opts in and the destination turns on the toggle for each kind; see Conversation content.

The grok_bot_agent_actions family, and skill.activated when a Bot emits it, carry Action Recording data. They flow only after a team admin turns on Action Recording on the Grok Bot page of the dashboard. Privacy Mode (Legacy) forces recording off.

Metrics

All metrics are monotonic delta sums. Correlation ids are on logs only, never on metric datapoints.

To get totals, sum the deltas per series. A series is the resource, the metric name, and the exact set of datapoint attributes. Windows for one series can overlap across flushes.

cursor.token.usage

• Unit: {token}
• Family: model_usage

cursor.tool.calls

• Unit: {call}
• Family: tool_calls
• Value: 1 per completed tool call

cursor.cost.usage

• Unit: USD (double)
• Family: model_usage

A best-effort cost estimate at event time, not an invoice. cursor.api.correction can amend it. For BYOK (bring your own key), it's the Cursor Token Rate only, not provider spend.

Calls with no Cursor-billed cost emit no datapoint rather than a zero: non-billable calls, errored calls (never charged), zero-cost calls, and BYOK or request-priced calls with no Cursor token fee. Aborted calls do export their provisional estimate, with cursor.api.status=aborted; those are the points most likely to be corrected later.

Log events

Severity numbers: INFO=9, WARN=13, ERROR=17.

Each event lists its severity, its body, and its family. The body is a constant event name on every event except conversation.*.

Common log attributes

cursor.api.request

• Severity: INFO
• Body: api_request
• Family: model_usage

cursor.api.error

• Severity: ERROR
• Body: api_error
• Family: model_usage

Raw error messages never export. Cursor plans to add low-cardinality kind and status attributes. Don't build on them until this page documents them.

cursor.api.correction

• Severity: WARN
• Body: api_correction_<kind>
• Family: model_usage

A billing finalization: Cursor retroactively did not bill the usage event. To correct your billing data, join on cursor.usage_event.id and drop the whole group. The record carries no cursor.model.name on purpose.

cursor.skill.activated

• Severity: INFO
• Body: skill_activated
• Family: skills_hooks_plugins

cursor.skill.path, cursor.skill.content_hash, and the cursor.skill.metadata.* pair identify which revision of a skill ran. They're attached in the IDE, CLI, and Cloud Agents for every trigger. Group by cursor.skill.path to follow one skill across edits, and by cursor.skill.content_hash or cursor.skill.metadata.version to compare revisions. For example, a skill whose frontmatter declares:

---name: deploymetadata:  id: acme.deploy  version: 1.4.0---

exports cursor.skill.metadata.id=acme.deploy and cursor.skill.metadata.version=1.4.0. The hash and the metadata come from the same copy of the file, so a record without cursor.skill.content_hash carries no cursor.skill.metadata.* either. Bot activations don't carry these attributes yet.

Grok Bot activations: a Bot reading a SKILL.md exports this same event with cursor.surface=grok_bot. Bot activations flow only when Action Recording is on.

• The record carries the shared grok_bot.* attributes, so it joins the turn's other actions.
• cursor.skill.name is the skill's folder slug.
• cursor.skill.trigger is agent_read or skill_name_in_prompt. A skill invoked with / or @ isn't recorded yet.
• cursor.skill.source is builtin for Cursor-managed skills, plugin for installed plugin skills, and user for the Bot's own. Other skills classify as on every other surface.
• cursor.grok_bot.tool_call.id is the id of the Read that activated the skill. It joins that call's tool_result row.
• Bot activations carry cursor.conversation.id and never cursor.request.id.

cursor.hook.execution_complete

• Severity: INFO; ERROR for failed and timeout
• Body: hook_execution_complete
• Family: skills_hooks_plugins

cursor.plugin.installed

• Severity: INFO
• Body: plugin_installed
• Family: skills_hooks_plugins
• Conversation id: none; an install isn't scoped to a conversation

cursor.cloud_agent.pull_request

• Severity: INFO for opened, merged, and closed; WARN for creation_failed
• Body: cloud_agent_pull_request_<kind>
• Family: cloud_agents
• Conversation id: the agent's bc-... id

Kinds:

• opened: the agent created a pull request, including through an automation's open-PR action. Linking a pull request that already existed exports nothing.
• merged: the pull request merged.
• closed: the pull request closed without merging.
• creation_failed: the agent tried to open a pull request and creation failed.

merged and closed come from the forge's webhook for a pull request linked to the agent's run.

• Dedupe: cursor.event.id on opened, merged, and closed is deterministic per agent, repository, pull request number, and kind. A redelivered webhook or a retried creation dedupes. A pull request closed, reopened, and closed again carries the same closed id both times.
• Not exported: branch names, the pull request URL, and the head SHA.

cursor.cloud_agent.setup

• Severity: INFO for started and completed; ERROR for failed
• Body: cloud_agent_setup_<kind>
• Family: cloud_agents
• Conversation id: the agent's bc-... id

cursor.cloud_agent.commit

• Severity: INFO
• Body: cloud_agent_commit
• Family: cloud_agents
• Conversation id: the agent's bc-... id

One record per commit a cloud agent pushes to its branch. Cursor exports it when GitHub's push webhook first records the commit for the agent.

• Hosts: GitHub only, on github.com and GitHub Enterprise. Agents working in GitLab, Bitbucket, or other hosted repositories produce no commit records.
• Skipped: merge commits, branch-sync commits, commits already on the repository's default branch, and commits made locally in the IDE or CLI.
• Dedupe: cursor.event.id derives from the repository and the SHA, so a redelivered push of the same commit carries the same id.
• Not exported: branch names and commit messages.

cursor.cloud_agent.artifact

• Severity: INFO
• Body: cloud_agent_artifact_created
• Family: cloud_agents
• Conversation id: the agent's bc-... id

cursor.cloud_agent.mcp_auth_error

• Severity: ERROR
• Body: cloud_agent_mcp_auth_error
• Family: cloud_agents
• Conversation id: the agent's bc-... id

An MCP server you connected rejected the run's credentials. That server's tool calls failed, and the run continued. It's an ERROR because only you can fix the integration. Alert on it to catch Automations and Cloud Agents silently losing an MCP server.

cursor.cloud_agent.review_followup

• Severity: INFO
• Body: cloud_agent_review_followup
• Family: cloud_agents
• Conversation id: the bc-... id of the agent that runs the follow-up

A review signal started a cloud agent run on an existing pull request. One record per started run. Two signals produce it today:

• A pull request comment, review, or review comment that mentions Cursor. It follows up on the pull request's active agent, or starts a new agent when none can take it.
• Bugbot Autofix, which starts an agent to fix Bugbot findings.

No comment, review, or finding text is exported.

The resource carries cursor.entrypoint=github_pr for github_comment and unspecified otherwise.

Shared grok_bot.* attributes

The grok_bot.* events record Bot actions from Action Recording.

• Family: grok_bot_agent_actions
• Surface: every record has cursor.surface=grok_bot.
• Bot identity: cursor.conversation.id on every record is the Bot's conversation id, which identifies the Bot. cursor.grok_bot.subagent.id names a subagent when one acted.

Every event describes an action, never its content. These events never export tool arguments or results, file paths or names, message bodies or recipients, credentials, card details, or the Auto-review classifier's reasoning. MCP arguments and results ship only as the opt-in cursor.conversation.tool_io record. Three exceptions are named on their events:

• the shell command text, secret-scrubbed and capped at 8 KiB
• the normalized browser URL and page title
• bare hostnames

Every free-text field is scrubbed for credential shapes, payment card numbers, US social security numbers, and OAuth tokens before it reaches your collector.

Every grok_bot.* event also carries these attributes:

cursor.grok_bot.mcp_tool_call

• Severity: INFO; ERROR for failure status
• Body: grok_bot_mcp_tool_call
• Family: grok_bot_agent_actions

One MCP tool call made by a Bot. This row never carries tool arguments or results. For http calls, a team with tool I/O enabled receives them as two cursor.conversation.tool_io records, joined to this row on cursor.grok_bot.tool_call.id.

• cursor.grok_bot.tool_call.id is on every MCP call.
• Connector (MCP) calls, including the browser tools on the Bot's computer, record here and never as tool_result. Each tool call records once.

cursor.grok_bot.shell_command

• Severity: INFO; WARN when blocked
• Body: grok_bot_shell_command
• Family: grok_bot_agent_actions

A shell command a Bot ran or was blocked from running.

• Timing: the record is written when the command settles, and its timestamp is the issue time. A long command's record arrives well after its timestamp.

• Password flags: Cursor redacts the password after a common client's password flag (mysql -pSecret, sshpass -p Secret, docker login -p Secret, redis-cli -a Secret). A bare mysql -p prompts for the password, so a lowercase identifier after it stays as the database name (mysql -u root -p inventory). Anything else after it is redacted.

cursor.grok_bot.browser_navigation

• Severity: INFO
• Body: grok_bot_browser_navigation
• Family: grok_bot_agent_actions

cursor.grok_bot.computer_use_session

• Severity: INFO
• Body: grok_bot_computer_use_session
• Family: grok_bot_agent_actions

A summary of one computer-use subagent session: counts and wall time only. No coordinates, typed text, or screenshots.

• cursor.grok_bot.turn.id: the parent turn that invoked the subagent
• cursor.grok_bot.subagent.id: the subagent itself
• cursor.grok_bot.tool_call.id: the invocation
• cursor.grok_bot.initiated_by: always subagent

cursor.grok_bot.tool_result

• Severity: INFO for success and cancelled; WARN for denied; ERROR for error
• Body: grok_bot_tool_result
• Family: grok_bot_agent_actions

One settled builtin tool call made by a Bot (read, web_search, send_to_user, task, shell, ...). Every builtin tool produces this row, so no tool a Bot can call goes unrecorded. Connector (MCP) calls are mcp_tool_call rows and never appear here.

• Joins: cursor.grok_bot.tool_call.id joins the row to the same call's tool_decision rows.
• Counting calls: one id can carry two tool_result rows when a call re-runs after a transient model-stream failure. To count calls, count distinct ids.

Reading outcome: it says how the call returned, not whether the action happened.

• The shells, browser and computer actions, and local-tool asks the person declined report a refusal as denied, with error_category user_rejected.
• Mail, routine writes, connector file transfers, subagent launches, and cloud agent actions hand a refusal back to the model as text. Their tool_result reads success, and the tool_decision row records the refusal.

cursor.grok_bot.tool_decision

• Severity: INFO for allowed and held; WARN for denied and timed_out
• Body: grok_bot_tool_decision
• Family: grok_bot_agent_actions

One decision about whether a Bot's tool call may run: who made it, through which approval mode, and what it was.

• A call can carry several decisions, each its own record. For example, Auto-review refuses to auto-allow, then a person answers the card.
• Decisions join the call's tool_result, mcp_tool_call, or computer_use_session row on cursor.grok_bot.tool_call.id.
• The classifier's rationale, the card copy, and the arguments never appear here.

What the sources mean:

• policy: every enforced Auto-review classification, allowed or denied, on any surface: the shells, connector calls, mail, routine writes, and cloud agent and subagent launches. A classifier that fails or misses its deadline records a policy denied. So does a review rule that sends a call to a person without classifying.
• human: how an Auto-review card ended, or a local-tool permission ask answered on the person's own computer (local_tool_permission). On a card, approval_mode is auto_review when the classifier escalated, and ask_human when the surface always asks (product feedback, claiming a mail inbox, placing a phone call, or a Chrome cookie import). "Always" and "never" answers record as allowed and denied, like a one-time answer.
• hook: a pre-tool hook's refusal.
• automatic: no gate spoke about the call. Every other builtin call that settled carries at least one decision.

Calls with no decision:

• A call the tool itself refused before any gate ran. Its tool_result reads denied.

• A card the person answers after the turn has ended (a credential fill request, a secret request, or a virtual card request). The answer arrives in a later turn. A virtual card request also ends the turn from inside its own call, so its tool_result reads cancelled.

• A call cancelled before any gate spoke. A cancelled call carries only the allowances and holds recorded before it was cut off.

• Refused, then answered: a call Auto-review refused and a person then answered carries both rows, policy denied then human, in event.sequence order.

• Approver: there's no approver attribute. Only a Bot's owner answers its cards, and the owner is the record's cursor.user.id.

cursor.grok_bot.file_transfer

• Severity: INFO for success; WARN for denied; ERROR for error
• Body: grok_bot_file_transfer
• Family: grok_bot_agent_actions

One file move a Bot tried between its computer and another endpoint:

• the user's machine
• a connected Google Drive, OneDrive, or Gmail account
• the Bot's context, for a file on the user's machine read straight into it

Details:

• Metadata only: which way, the far end, how many bytes moved, and how it settled. The path, the file name, and the content never export.
• Not this event: a read of a file on the Bot's own computer is a tool_result row.
• Joins: cursor.grok_bot.tool_call.id joins the row to the call's tool_result and, for a refused move, to its tool_decision.

cursor.grok_bot.message_delivery

• Severity: INFO for sent and held; ERROR for failed
• Body: grok_bot_message_delivery
• Family: grok_bot_agent_actions

One outbound message from a Bot, to one of:

• its user, in the Grok Bot chat
• another of the user's Bots
• a Slack or Discord conversation the Bot was reached through
• outside email recipients
• the user's Mac Messages app
• a draft card the user sends or discards themselves

The row says where the message went and whether it got there. It never says what the message said or names who got it: no body, subject, recipient, attachment name, or length. cursor.grok_bot.tool_call.id joins the row to the tool_result of the same send call.

cursor.grok_bot.routine_run

• Severity: INFO for success and cancelled; ERROR for error
• Body: grok_bot_routine_run
• Family: grok_bot_agent_actions

One finished routine run by a Bot: which routine fired, why, how it ended, and how long it took. The record never carries the routine's prompt, its name, or the turn's text.

• Provenance: Cursor records the row when it closes the run (server provenance). A run is recorded whether or not the Bot's computer was watching. The row carries no box.id, event.sequence, or tool_call.id.

• Fixed values: always cursor.grok_bot.initiated_by=routine and cursor.entrypoint=automation.

• Joins: cursor.grok_bot.turn.id is the turn the run executed in, so the run's own tool_result, shell_command, and mcp_tool_call rows join on it. A run that executed as a routine subagent carries no turn.id. Neither does a run that failed after its team was known but before its turn was planned; that run is recorded with outcome error.

Not recorded:

• A run that pauses on an approval and is settled by the resumed turn. Neither the pause nor the resumed turn records a row. A turn that ends paused for the user without an approval still records success.
• A run that failed before the Bot ran its turn, while its team wasn't known yet.
• A run the dispatcher closed as failed before any turn started, such as when delivery failed or the agent's queue was full.
• Runs of a personal (team-less) owner. Action Recording is a team feature, so these are skipped like every other Bot action.

cursor.grok_bot.guardrail

• Severity: WARN when the guardrail changed the turn (warned, stopped): a nudge, a stop, or a wait that ended refused or unanswered. INFO when it only observed or the turn went on (continued)
• Body: grok_bot_guardrail
• Family: grok_bot_agent_actions

A guardrail stepping in on a Bot turn. Four things trip one:

• the loop detector, on repeated output or tool calls
• a site's bot defense refusing the Bot's browser
• Auto-review stopping a tool call to ask a person, and the wait that followed
• the organization's inference hook refusing the turn's model request

Details:

• Coded fields only: the classifier's rationale and the card's copy never export.

• Decisions live elsewhere: the decision itself (Auto-review's refusal, the person's answer) is a tool_decision row and isn't repeated here. An escalation row joins it on cursor.grok_bot.decision.id.

• One row per trip: a bot-defense wall counts once per episode, so a page that stays on the same wall through reloads is one row.

Escalations: one card produces two rows, in the order they happened.

1. tool_escalation is the ask. A card was raised because a call under review couldn't run without a person.
2. pause is the end of the wait. The person allowed the action (resumed) or refused it (denied), or nobody answered before the card expired or was withdrawn (abandoned). When the wait ended because a person stopped or redirected the turn instead of answering, the second row is interrupted.

Both rows carry the escalated tool's cursor.tool.name, the call's cursor.grok_bot.tool_call.id, and the card's id as cursor.grok_bot.decision.id. That id is the value the call's human tool_decision row carries, so the ask, the wait, and the answer join on one key.

• cursor.grok_bot.tool_call.id is on the escalation kinds. It's absent on the detections and on inference_hook, which aren't attributed to one tool call.
• An inference hook refusing a subagent's model request names the subagent in cursor.grok_bot.subagent.id. The hook's deny message and reference id never export.
• A call Auto-review refused with no one to ask raises no card and carries only its tool_decision.

cursor.grok_bot.delegation

• Severity: INFO for dispatched, and for completed with success or stopped; ERROR for completed with error
• Body: grok_bot_delegation
• Family: grok_bot_agent_actions

Work a Bot handed to another agent, and the result coming back. The delegate is a background subagent the Bot dispatched, or a Cursor cloud agent it launched or replied to.

• Ids and outcome only: never the prompt, the result text, or the delegate's own actions. A subagent's tool calls are its own grok_bot.* rows with initiated_by=subagent. A cloud agent's run is in the cloud_agents family.

• Two records per delegation, sharing target_id: dispatched when the work was handed over, and completed when the result came back to the Bot.

• Turn: a completed record takes the turn that received the result as its turn.id, not the dispatching turn's.

• Tool call: cursor.grok_bot.tool_call.id is the dispatching call, or the stop call on a subagent_stop record. It's on the dispatched record and on a subagent's completed record, and absent on a cloud agent's completion.

Known limits:

• Not recorded: a steer injected into a cloud agent's running turn (no new run), a launch or reply Cursor rejected, a cloud agent cancel, a run someone else started that the Bot only watches, and a routine's subagent waking its parent.
• A stopped subagent can still deliver an error completion afterwards, so one target_id can carry both a stopped and an error record.
• A cloud agent's completed record is best-effort: when the Bot re-watches an agent it launched in an earlier turn, the completion can carry kind cloud_agent_launch, and a launch re-watched mid-run can leave its dispatched without a completed. Pair the two records on target_id, and build your pipeline to accept a dispatched record with no completed.
• Delivery is at-least-once like every grok_bot.* row: a launch, reply, or completion retried after a crash can record twice for one target_id. Dedupe on cursor.event.id before you pair records.

Conversation content

• Severity: INFO on all three events
• Family: conversation_content

These are the only log records whose body is a payload (message text, or one side of a tool call) instead of a constant event name. Route on the log event name, as with every other family, and don't parse the body to tell them apart:

• cursor.conversation.user_message is a prompt.
• cursor.conversation.assistant_message is a response.
• cursor.conversation.tool_io is the arguments or the result of a tool call.

Body: scrubbed text. Messages are capped at 32 KiB, and each side of a tool call at 8 KiB. cursor.conversation.content_truncated is set whenever the exported body is a prefix of the redacted text, whether the source crossed the cap or redaction pushed it over. On tool_io, it's also set when scrubbing left a body within the cap unparseable, or dropped the tail of a JSON document the connector had cut.

Identity:

• Records carry the common log attributes.
• cursor.conversation.id joins them to the conversation's api.request, skill.activated, hook.execution_complete, cloud_agent.*, and grok_bot.* logs.
• The only user identifiers are the optional cursor.user.* resource attributes. The log attributes carry none.
• Records don't reliably carry cursor.request.id, cursor.usage_event.id, or, on message records, cursor.grok_bot.turn.id, so don't join on them. Grok Bot tool_io records carry turn.id as a shared grok_bot.* attribute.

Surfaces: Cloud Agents and Grok Bot only. IDE, CLI, and desktop conversations aren't on this family yet. To separate the two surfaces, filter or route on cursor.surface.

• Cloud Agent conversations arrive with cursor.surface=cloud_agent on the resource. There, tool_io covers every MCP and builtin tool call.
• A Cloud Agent's Task subagent exports its own tool_io and assistant_message records under its own cursor.conversation.id when it finishes, behind the same toggles as its parent. Cursor doesn't export user_message records for subagents.
• Grok Bot conversations arrive with cursor.surface=grok_bot, alongside the Bot's grok_bot.* action logs when Action Recording is on. There, tool_io covers MCP calls over http.

Toggles: each event flows only with the team opt-in and its destination toggle on. user_message needs Prompts, assistant_message needs Responses, and tool_io needs Tool I/O. The setup page covers the toggles.

All three events carry these attributes:

cursor.conversation.user_message

• Severity: INFO
• Body: the scrubbed text of a user prompt.

cursor.conversation.assistant_message

• Severity: INFO
• Body: the scrubbed final assistant text for the response.

cursor.conversation.tool_io

• Severity: INFO
• Body: the scrubbed compact JSON of one side of a tool call, at most 8 KiB. Each tool call exports two records, one per cursor.conversation.tool_io.direction.

When records export:

• cursor.surface=grok_bot: per MCP tool call executed over http transport. stdio calls on the Bot's computer report metadata only and produce no tool_io record.
• cursor.surface=cloud_agent: per finished MCP or builtin tool call (shell, file read, edit and delete, search, web fetch, Task, and the rest) in a turn, including the calls of in-process subagents, exported after the turn ends. A Task subagent runs as its own Cloud Agent and exports its calls under its own cursor.conversation.id when it finishes.
• Timing (cloud_agent): each record carries the tool call's completion time, and Cursor exports it when the turn or subagent run ends. A long turn can deliver records timestamped well before they arrive, so order by record timestamp, not arrival time.
• Every surface: a call whose tool-call id does not read as an opaque identifier (letters, digits, _ . : $ / + = -, at most 128 characters) produces no tool_io records.

MCP and builtin content:

• MCP: the arguments record carries the JSON object the caller sent (the Bot on grok_bot, the agent on cloud_agent), and the result record carries the connector's reply. On success that is the tool's text and structured content; on failure, the error, rejection, or denial message.
• Builtin: the records carry the tool's own arguments and result as JSON (protobuf JSON field names). A file read exports the text it read. A Task result leaves out the subagent's transcript, whose calls export as records of their own.

Stripped and capped:

• Each side is capped at 8 KiB. Truncated bodies below covers how cursor.conversation.content_truncated marks a cut body.
• MCP: image bytes are replaced with their MIME type.
• Builtin: binary fields such as images and screenshots are left out.
• Both sides pass the scrubber described below.

Join keys:

• cursor.tool_call.id: on both records of a call; joins the two sides on every surface.
• cursor.grok_bot.tool_call.id (grok_bot only): the same value. Joins the records to the call's cursor.grok_bot.mcp_tool_call and cursor.grok_bot.tool_decision rows. Joining the two tool_io sides on it is deprecated: use cursor.tool_call.id.
• On cursor.surface=grok_bot, the records also carry the shared grok_bot.* correlation attributes (provenance, turn.id, tool_call.id, event.sequence), unchanged. On cursor.surface=cloud_agent, they carry no grok_bot.* attributes.
• Turn (cloud_agent): cursor.conversation.turn.id is the turn the call ran in, the same value as that turn's prompt and response records.
• Task subagents (cloud_agent): the parent's Task result record names the subagent as success.agentId in its body. That value is the subagent's cursor.conversation.id, so join on it to attach the subagent's records to the parent call. The subagent's records carry no cursor.subagent.id.
• In-process subagents (cloud_agent, rare): a call carries the turn that started the subagent and names the subagent in cursor.subagent.id.

cursor.tool.name, cursor.tool.status, and cursor.mcp.server.name repeat the metadata row's values so each record is readable on its own.

Toggles: the destination's Tool I/O toggle, in addition to the team opt-in.

Truncated bodies: when cursor.conversation.content_truncated is true, part of the source is missing. Check the flag before parsing; a flagged body that parses is still incomplete. A flagged body is one of:

• A prefix of the redacted text, which doesn't parse as JSON. Either the source crossed the cap, or scrubbing left it unparseable and Cursor exported it flagged instead of exporting a less-scrubbed body.
• Valid JSON in which a document the connector had cut was closed at its last whole member, and the rest dropped.

Credential keys: both sides pass the same scrubber as message text. A second, key-based pass redacts the value of any JSON member or assignment whose key names a credential, whatever the value looks like. A key names a credential when:

• one of its words (split on _, -, ., space, and camel case) is a credential word: password, passcode, passphrase, secret, token, auth, authorization, credential, cookie, pin, otp, ssn, and their compounds such as client_secret, X-Auth, secretValue, or passwordHash
• its last word is pass or pwd (db_pass)
• key follows a qualifier such as api, access, secret, private, or account (api_key, x-api-key, private_key, AccountKey)

Values that stay:

• A key whose last word is metadata about a credential keeps its value (token_count, token_type, api_key_id, auth_url).
• A bare key redacts only a value shaped like a minted token, so an issue key exports and an API key doesn't.
• A boolean or null under a credential key stays.

Nested credentials, headers, and tables:

• An object or array under a credential key keeps its shape. Every leaf inside becomes the marker except its metadata members (name, type, id, scopes, created_at, and similar). So secrets: [{"name":"NPM_TOKEN","value":"..."}] exports the name and replaces the value.
• Header rows count too. In [{"name":"Authorization","value":"Basic ..."}], the value or val sibling of a name, key, header, id, label, or field member on the list is redacted. So is a row that marks its own value as secret (masked: true, or type of SecureString, CONCEALED, or password), and the second item of a two-item array whose first is on the list (["password","..."]).
• Card fields held as numbers ("cvc": 123) become [REDACTED: Card].
• A US social security number in the 123-45-6789 shape becomes [REDACTED: SSN].
• ASCII \uXXXX escapes are decoded before scrubbing.
• In a table given as an array of arrays whose first row names the columns (a Sheets values range), every column whose header names a credential or a card field takes the marker in the rows below.
• A private-key block split across the items of one array (lines of a file, text blocks of a result) is redacted from its BEGIN line through its END line. One split across unrelated fields isn't.

JSON inside text:

• JSON a connector returns as text gets the same rules as structured content. A string leaf that holds a JSON object or array (an MCP text block, a webhook body, a log message) is parsed and walked by key like the document around it. So is a document encoded again inside one of those, at any depth up to the 256-level cap.
• The text around a document stays text. A summary line, a markdown fence, or a trailing note is scrubbed as prose, and an NDJSON leaf is walked line by line.
• Cursor also reads the near-JSON spellings connectors produce: " for quotes, a trailing comma before a closer, and a Python str(dict) with single quotes and True / False / None.
• A document the walk didn't change exports as the connector wrote it, whitespace and escapes included.
• A document with a redaction in it exports compact: whitespace removed, \u00e9-style escapes and \/ respelled as the characters they name, only the last of duplicate keys kept, and a Python repr respelled as JSON. Numbers keep their digits (12345678901234567890, 1.0, -0).
• A document the connector cut short ([output truncated], a closed connection) is closed at its last whole member and walked. When that drops anything, the record is flagged with content_truncated.

See MCP tool I/O for what the scrubber doesn't catch.

Identity and joins

Exported logs carry no OpenTelemetry trace_id or span_id fields. Use cursor.conversation.id and cursor.grok_bot.turn.id to correlate Bots and turns. Metrics carry no correlation ids; use api.request logs for per-conversation token totals.

See Joining sessions on the setup page for recipes.

Delivery semantics

• Logs are at-least-once. Transient failures recover automatically for about 7 days; dedupe on event.id. Terminal rejections (persistent 4xx, bad payloads) are not replayed.
• Metrics are at-most-once. Failed metric requests are not retried or replayed.
• No ordering guarantee. Corrections can arrive after the requests they amend; order by record timestamp.
• OTLP partial success is honored. Rejected items are not re-sent.
• No backfill from before destination activation. Source retention upstream of export is also about 7 days (separate from the delivery retry window).