We’re evaluating the Enterprise Plan’s OpenTelemetry export and hit a gap around the cloud-agent log events I’d love guidance on.
Per the Wire Reference, the export includes a cursor.cloud_agent.* log-event family -cursor.cloud_agent.setup, .artifact, .pull_request (opened / creation_failed), and .mcp_auth_error.
I’m especially interested in cursor.cloud_agent.pull_request, and I’m trying to understand what makes these events show up.
From what I’ve seen so far, cloud agents surface in the export as regular usage records (cursor.surface=cloud_agent), but none of the cursor.cloud_agent.* lifecycle events appear alongside them - the log events are the editor ones (api_request, skill_activated, hook_execution_complete, plugin_installed, api_error, api_correction).
Questions:
Is the cursor.cloud_agent.* log-event family gated behind a separate setting (a Team Settings → OpenTelemetry Export toggle, an org flag, or a beta gate), or does it export by default once Cloud Agents are used?
Is cursor.cloud_agent.pull_request emitted only when a cloud agent actually opens a PR?
What attributes does cursor.cloud_agent.pull_request carry — PR URL / repo / branch, and an agent or run id?
Is the OTLP eventName field the canonical carrier of these event names, or are they distinguished only by the log body?
Any plans or known limitations for the cloud-agent log events while the export is in beta?
1. No separate toggle or beta gate. cloud_agents is just one of the event families on the export destination, on by default (auto_enable_new_families) once you have a destination configured. The reason you’re not seeing them is that each one only fires on a specific condition: setup only on fresh-machine install runs (snapshot-booted runs skip it), artifact only when a run produces an artifact, mcp_auth_error only on an MCP credential rejection, and pull_request only on failures right now (see 2). Docs: OpenTelemetry Export / Wire Reference.
2. Almost. kind = creation_failed fires when a PR attempt fails; kind = opened isn’t being emitted yet, so a successful PR currently produces no pull_request record at all. The “may be sparse while the producer rolls out” wording undersells that, so I’ve let the team know it should read more plainly and passed along your interest in getting opened emitted.
3. .kind (always), plus .number and .draft (opened only). The run id is cursor.conversation.id, which for cloud agents is the bc-... id. PR URL, repo, and branch aren’t on the event, but you can get them by joining that bc-... id to the Cloud Agents APIGET /v1/agents/{id}, whose git.branches[] entries include repoUrl, branch, and prUrl.
4. eventName is canonical (cursor.cloud_agent.pull_request). The body is a derived string (cloud_agent_pull_request_<kind>) and .kind is always set, so you can filter on either if your backend doesn’t index eventName.
5. Current gaps: opened isn’t emitted yet; setup events are skipped on snapshot-booted runs; no PR URL/repo/branch on pull_request; cursor.user.id and cursor.request.id aren’t set on cloud_agent.* (use cursor.conversation.id to correlate); and cursor.entrypoint is unspecified. New events land additively, and auto_enable_new_families controls whether they turn on automatically. I’ll follow up here if opened ships.