@cursor/july 0.1.111 → 0.1.113

package/docs/guides/mcp-oauth.md

@@ -1,174 +1,164 @@
 ---
 title: "Host MCP OAuth"
-description: "Authorize defineConnection({ url, oauth: true }) with agent-sdk mcp oauth, store tokens locally, and push MCP_OAUTH_* secrets to hosted deployments."
+description: "Authorize a private MCP server locally, constrain its tools, and carry its credentials onto a hosted agent."
 ---
 
-# Host MCP OAuth
+# Connect a private MCP server with OAuth
 
-Use host MCP OAuth when your agent talks to a remote MCP server that
-speaks OAuth, and you want credentials on the serve host (or the hosted
-engine) instead of a Cursor account connector. Local login writes tokens
-next to your Cursor credentials. `--store` copies those tokens onto the
-deployment as secrets so prod can reconnect after a redeploy. Hosted
-Connect lets the current process retry.
+Host MCP OAuth lets an Agent SDK process authorize a remote MCP server
+without putting tokens in the agent's source or workspace. Use it when
+the server speaks OAuth and its credentials should belong to the serve
+host instead of a person's Cursor account.
 
-The companion skill is
-[`skills/mcp-auth/SKILL.md`](../../skills/mcp-auth/SKILL.md).
+## Use a private MCP tool locally
 
-## What can host MCP OAuth do?
+Declare the remote server, authorize it once in the browser, and start
+the agent. The next local turn can call the server's named tools with
+the credentials stored on that host.
 
-- Authorize `defineConnection({ url, oauth: true })` with a browser PKCE
-  flow (`agent-sdk mcp oauth <connection>`)
-- Keep tokens in `mcp-auth.json` under the CLI config directory, bound
-  to that connection's resource URL
-- Upsert deployment secrets with `--store` so the next deploy seeds the
-  same tokens from env. Hosted Connect lets the current process retry.
-- Use `advertiseTools: true` when local turns should call the server by
-  name. Host tools can still call it through `ctx.host.mcp`.
+```ts
+// agent/mcp-connections/inventory.ts
+import { defineConnection } from "@cursor/july/connections";
 
-Prefer a Cursor account MCP connection when the connector already lives
-in the signed-in account dashboard:
+export default defineConnection({
+  url: "https://mcp.example.com/inventory",
+  oauth: true,
+  advertiseTools: true,
+});
+```
 
-```ts
-defineConnection({ cursorAccount: true }) // every connected connector
-// or servers: "*" / servers: ["Linear"]
+```bash
+agent-sdk mcp oauth inventory
+agent-sdk run --dir . \
+  --message "Which east-coast warehouse has SKU-142 in stock?"
 ```
 
-Use host OAuth when the server is yours (or private to your network)
-and the host must hold tokens.
+The filename is the connection name used by the CLI and
+`ctx.host.mcp`. Changing the server URL invalidates its saved
+authorization, so run `mcp oauth` again after moving the endpoint.
 
-## How do I declare a host-OAuth connection?
+## Connect on first use
 
-Add one file under `agent/mcp-connections/` (model + host) or
-`agent/host-connections/` (host + `mcp oauth` only). The filename is the
-connection name you pass to the CLI and to `host.mcp`.
+You can also let the first unauthenticated call ask for authorization.
+The turn parks and the playground shows **Connect**. Finish the browser
+flow, return to the playground, and confirm **Connected**; the same call
+retries and the turn continues without restarting the agent.
+
+```bash
+agent-sdk serve --dir . --dev
+```
+
+Connect authorizes the process that is running now. It does not seed
+credentials for a future hosted replacement; use `--store` for that
+separate outcome.
+
+## Keep privileged tools behind a wrapper
+
+Put a connection under `agent/host-connections/` when the model should
+not receive the MCP server's tools directly. A server tool can expose
+one constrained operation while `ctx.host.mcp` keeps the broader server
+on the host.
 
 ```ts
-// agent/mcp-connections/inventory.ts
+// agent/host-connections/inventory.ts
 import { defineConnection } from "@cursor/july/connections";
 
 export default defineConnection({
   url: "https://mcp.example.com/inventory",
   oauth: true,
-  description: "Inventory MCP.",
+  tools: ["lookup_stock"],
+});
+```
+
+```ts
+// agent/tools/get_stock.ts
+import { defineTool } from "@cursor/july/tools";
+import { z } from "zod";
+
+export default defineTool({
+  description: "Read stock for one approved region.",
+  inputSchema: z.object({
+    sku: z.string(),
+    region: z.enum(["us-east", "us-west"]),
+  }),
+  async execute(input, ctx) {
+    const result = await ctx.host.mcp.callTool(
+      "inventory",
+      "lookup_stock",
+      input
+    );
+    return {
+      ok: result.isError !== true,
+      stock: result.structuredContent ?? null,
+    };
+  },
 });
 ```
 
-Rules of the road:
+The model sees `get_stock`, not the unrestricted inventory server.
+Use this shape when code should own an allowlist, approval, or other
+side-effect gate.
 
-- `oauth: true` is required for `agent-sdk mcp oauth`
-- A file under `mcp-connections/` is visible to the model and to `ctx.host.mcp`. A file under `host-connections/` stays on the host.
-- Declare expected secret names on the agent when you plan to `--store`:
+## Keep OAuth across hosted replacements
+
+Declare the server's egress domain and the OAuth secret names, authorize
+from a signed-in machine, then store the credentials and redeploy. The
+next hosted process can reconnect without opening a browser.
 
 ```ts
 // agent/agent.ts
 export default defineAgent({
-  // …
   hosting: {
+    egressDomains: ["mcp.example.com"],
     secretNames: [
       "MCP_OAUTH_INVENTORY_ACCESS_TOKEN",
       "MCP_OAUTH_INVENTORY_REFRESH_TOKEN",
       "MCP_OAUTH_INVENTORY_CLIENT_ID",
     ],
-    // Hosted engines need an explicit allowlist for non-bootstrap hosts.
-    egressDomains: ["mcp.example.com"],
   },
 });
 ```
 
-Secret names follow `MCP_OAUTH_<CONNECTION>_*` where `<CONNECTION>` is
-the connection filename uppercased with non-alphanumerics turned into
-underscores (`inventory` → `MCP_OAUTH_INVENTORY_…`).
-
-## How do I authorize locally?
-
-From the agent project (Node 22.13+, not Bun):
-
-```bash
-agent-sdk mcp oauth inventory
-```
-
-What happens:
-
-1. The Agent SDK loads the connection file and checks `oauth: true`
-2. It opens the authorization URL in your browser
-3. The callback lands on `http://localhost:8787/callback`
-4. Tokens land in `mcp-auth.json` under the CLI config directory
-  (override with `AGENT_SERVE_CONFIG_DIR`)
-
-If you're already authorized, the command prints that and exits. Re-run
-it after rotating tokens on the MCP server, or after you change the
-connection URL (tokens are bound to the resource URL).
-
-## How do I store credentials on a hosted deployment?
-
-Authorize once. Then get the tokens onto the deployment.
-
-On a hosted engine, finishing Connect lets the current process retry.
-Self-hosted serve writes tokens locally only.
-
-`--store` from a signed-in laptop is the reliable way to put
-`MCP_OAUTH_*` on the next deploy. If `agent-sdk secrets list` is
-empty, run `--store` and redeploy.
-
-From a laptop, push secrets with the CLI:
-
 ```bash
 agent-sdk mcp oauth inventory --store
-# optional:
-#   --slug my-agent
-#   --team <cursor-team-id>
+agent-sdk secrets list my-agent
+agent-sdk deploy
 ```
 
-`--store` upserts:
-
-| Secret | Source |
-| --- | --- |
-| `MCP_OAUTH_<NAME>_ACCESS_TOKEN` | access token (required) |
-| `MCP_OAUTH_<NAME>_REFRESH_TOKEN` | refresh token when the server returns one |
-| `MCP_OAUTH_<NAME>_CLIENT_ID` | dynamic client id when registration returned one |
-
-You must be signed in (`agent-sdk login`) with permission to set secrets
-on that slug. Secrets apply on the **next** deploy. Run
-`agent-sdk deploy` after `--store`. A fresh pod sees `MCP_OAUTH_*`
-only after that deploy.
+`--store` writes deployment secrets; it does not restart the current
+engine. Follow the CLI or dashboard prompt to redeploy, then exercise
+the hosted agent.
 
-On the engine, when `mcp-auth.json` is empty, serve seeds the OAuth
-provider from those env vars so host MCP calls work without a browser
-on the pod.
+These credentials belong to the deployment, not to the person who
+clicked Connect. Anyone able to use that agent can reach the MCP
+capabilities you expose, so keep privileged servers host-only or narrow
+their tool list.
 
-These secrets are deployment-wide. Anyone who can list or set secrets
-on that slug, and the hosted engine's runtime env, can use them. That
-is the same blast radius as `--store`. They are not scoped to the
-caller who clicked Connect. `cursorAccount: true` tokens stay on the
-Cursor backend for the deployment service account and do not use
-`MCP_OAUTH_*`.
+## Choose where credentials live
 
-## How do host tools call the server?
+Use the credential shape that matches who should own access:
 
-```ts
-const result = await ctx.host.mcp.callTool(
-  "inventory",
-  "list_warehouses",
-  { region: "us-east" }
-);
-```
+- Choose `cursorAccount: true` for connectors already authorized under
+  MCP in the Cursor dashboard. Their tokens stay on the Cursor backend.
 
-The model can call the same server. Use a host tool when the write needs
-an allowlist or other deterministic gate.
+- Choose `url` with `oauth: true` when the serve host or hosted
+  deployment should hold OAuth credentials.
 
-## What if authorization fails?
+- Choose `url` with static `headers` when the server uses an API key or
+  bearer token instead of OAuth.
 
-| What you see | What to do |
-| --- | --- |
-| `must be defineConnection({ url, oauth: true })` | Add `oauth: true` on that connection, or pick the right connection name |
-| Callback never completes | Keep port `8787` free; finish the browser login on this machine |
-| Hosted calls unauthorized after Connect or `--store` | Confirm secrets with `agent-sdk secrets list <slug>`, then redeploy |
-| Tokens ignored after URL change | Expected: resource URL binding drops stale entries. Re-run `mcp oauth` |
+Host OAuth and per-session `auth` are different identity models and
+cannot be combined on one connection. Use per-session auth when each
+caller needs a different downstream identity.
 
-## What's next
+## Related
 
-- [MCP connections](../reference/connections.md): transports, account MCP
-- [CLI](../reference/cli.md#mcp-oauth): full flag list for `mcp oauth`
-- [Deployment](../deployment.md): secrets, egress, and hosted engines
-- [Fix common agent problems](../troubleshooting.md): more symptom → fix tables
+- [`skills/mcp-auth/SKILL.md`](../../skills/mcp-auth/SKILL.md): the
+  companion setup procedure for coding agents
+- [MCP connections](../reference/connections.md): transports, account
+  connectors, per-session auth, and tool filtering
+- [CLI reference](../reference/cli.md#mcp-oauth): OAuth command flags
+  and browser callback behavior
+- [Deployment](../deployment.md): hosted secrets and egress
+- [Troubleshooting](../troubleshooting.md): authorization symptoms and
+  remedies

package/docs/guides/opentelemetry.md

@@ -1,224 +1,155 @@
 ---
 title: "OpenTelemetry"
-description: "Push session, turn, and tool traces from the serve process to an OTLP collector you run."
+description: "Send agent traces and metrics to an OTLP collector, follow one conversation, and add domain telemetry."
 ---
 
-# OpenTelemetry
+# Observe an agent with OpenTelemetry
 
-Agent SDK can push traces, metrics, and logs from the serve process to
-an OTLP collector you run. Point the process at the collector with
-standard `OTEL_EXPORTER_OTLP_*` environment variables, or pass the
-same options to `serve({ otel })`. Traces cover the inbound request,
-each turn, and every tool call.
+OpenTelemetry connects an agent turn to the observability system your
+team already uses. Once you configure an OTLP collector, each request,
+model turn, tool call, and subagent appears alongside token, tool, and
+cost metrics from the serve process.
 
-Export is opt-in. Nothing leaves the process until you set an endpoint.
+Export is opt-in. Nothing leaves the process until you configure a
+destination.
 
-## What does Agent SDK export?
+## Connect an OTLP collector
 
-| Signal | Default | What you get |
-| --- | --- | --- |
-| Traces | on | `agent_sdk.http` (per request) and `agent_sdk.turn` → `agent_sdk.tool` / `agent_sdk.subagent` |
-| Metrics | on | `cursor.token.usage`, `cursor.tool.calls`, `cursor.cost.usage`, plus `agent_sdk.*` session and turn counts |
-| Logs | off | Session events as log records. Prompt text, tool payloads, and failure messages stay off unless you opt in |
-
-Turn off a signal with `traces: false`, `metrics: false`, or `logs: false`
-on `serve({ otel })`. Logs also turn on when you set `OTEL_LOGS_EXPORTER` to
-anything other than `none`, or when you set the content flags below.
-
-## How do I turn OpenTelemetry export on?
-
-Set a collector URL in the serve process environment:
+Set the collector endpoint, start the agent, and send it a message. You
+should see an `agent_sdk.http` request span and an `agent_sdk.turn`
+trace, with any tool or subagent work nested under the turn.
 
 ```bash
 export OTEL_EXPORTER_OTLP_ENDPOINT=https://otel.example.com
-export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer …"
-```
+export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer $OTEL_TOKEN"
+export OTEL_SERVICE_NAME=incident-agent
 
-The default wire format is OTLP/HTTP protobuf. That matches
-[Cursor enterprise OpenTelemetry Export](https://cursor.com/docs/enterprise/opentelemetry-export).
-Set `OTEL_EXPORTER_OTLP_PROTOCOL=http/json` when your collector only
-accepts JSON. The runtime accepts `http/protobuf` and `http/json`.
-`grpc` falls back to protobuf and logs a warning.
-
-`OTEL_EXPORTER_OTLP_ENDPOINT` is the base URL. The runtime appends
-`/v1/traces`, `/v1/metrics`, and `/v1/logs`. If you pass a signal path,
-it is stripped back to the base first.
-
-To send each signal to a different collector, omit the base URL and set
-the per-signal vars:
-
-```bash
-export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=https://traces.example.com/v1/traces
-export OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=https://metrics.example.com/v1/metrics
-export OTEL_EXPORTER_OTLP_LOGS_ENDPOINT=https://logs.example.com/v1/logs
+agent-sdk serve --dir . --dev
 ```
 
-Optional:
-
-| Variable | Effect |
-| --- | --- |
-| `OTEL_SERVICE_NAME` | Resource `service.name`. Default `cursor` |
-| `OTEL_LOG_USER_PROMPTS=1` | Include user prompt text on logs and span events |
-| `OTEL_LOG_TOOL_CONTENT=1` | Include tool payloads and failure text (truncated) |
-
-`serve(dir, { otel: false })` turns export off even when env is set.
-
-You can pass the same options object to `serve(dir, { otel })`.
-Precedence is `serve({ otel })` over env.
+The default protocol is OTLP/HTTP protobuf. If you already call
+`serve()` from TypeScript, you can configure the same destination in
+code:
 
 ```ts
 await serve(dir, {
   otel: {
-    serviceName: "cursor",
+    serviceName: "incident-agent",
     exporters: [
       {
         url: "https://otel.example.com",
-        protocol: "http/protobuf",
-        headers: { Authorization: "Bearer …" },
+        headers: {
+          Authorization: `Bearer ${process.env.OTEL_TOKEN ?? ""}`,
+        },
       },
     ],
   },
 });
 ```
 
-Multiple `exporters` fan out to every destination. Restrict one
-destination with `signals: ["traces"]`.
+Use environment variables when you start the agent with
+`agent-sdk serve`. Use `serve({ otel })` when your TypeScript
+application starts the server itself.
 
-`defineOtel` / `agent/otel.ts` (`@cursor/july/internal/otel`) is
-factory-only. Discovery still loads that file for Cursor factory
-agents. It is not a public Agent SDK export.
+## Follow one conversation
 
-The companion skill is [`skills/otel/SKILL.md`](../../skills/otel/SKILL.md).
+Copy the complete session ID from the playground or session API, then
+filter your observability system on either `agent_sdk.session_id` or
+`cursor.conversation.id`. Every turn in that conversation carries the
+same value, including follow-ups and tool work.
 
-## What spans does a session produce?
+The trace shape stays small:
 
 ```text
-agent_sdk.http          inbound channel request (W3C traceparent)
-agent_sdk.turn          one root per turn (`agent_sdk.session_id` = session id)
-  ├─ agent_sdk.tool
-  └─ agent_sdk.subagent
-       └─ agent_sdk.tool
-```
-
-Conversational sessions stay on `session.waiting` and can take more
-turns, so there is no `agent_sdk.session` span — it would never end
-and OTel only exports ended spans. Each turn is its own root. Inbound
-HTTP is a separate SERVER span (it extracts W3C `traceparent`) and
-does not parent the turn, so the turn tree can export when the turn
-ends. Hosted flush ends that SERVER span before the one-shot export so
-`agent_sdk.http` is in the same batch.
-
-Turns that resume after restore, or a direct `callTool` with no
-`turn.started` in this process, open a synthetic turn span so tool
-calls still nest.
+request: agent_sdk.http
 
-## Which attributes land on the wire?
-
-Every signal carries these resource attributes:
-
-- `service.name` (`cursor` unless you override it)
-- `cursor.entrypoint=sdk_ts`
-- `cursor.surface=unspecified`
-- `agent_sdk.framework=@cursor/july`
-
-Span attributes (not process resource attributes — one serve process
-handles many sessions):
-
-- `agent_sdk.session_id` / `cursor.conversation.id`: the session id.
-  Search all turns for one conversation with `@agent_sdk.session_id`.
-
-Shared names (same keys as enterprise export):
-
-- `cursor.conversation.id`: the session id
-- `cursor.model.name`
-- `cursor.token.usage` with `cursor.token.type` of `input`, `output`,
-  `cache_read`, `cache_creation`, or `reasoning`
-- `cursor.tool.calls` with `cursor.tool.name`, `cursor.tool.kind`, and
-  `cursor.tool.status`
-- `cursor.cost.usage` (USD)
-
-Agent SDK only (`agent_sdk.*`): session id, agent name, turn id, channel,
-call id, subagent name, session mode, and HTTP duration
-(`agent_sdk.http.duration`).
+turn: agent_sdk.turn
+      |- agent_sdk.tool
+      `- agent_sdk.subagent
+         `- agent_sdk.tool
+```
 
-## How do I emit my own metrics?
+A conversation can produce several turn traces, so use the session ID
+as the join key instead of expecting one long-lived session span.
 
-`ctx.host.otel` is always present on tools, hooks, and channel
-handlers. Counters and histograms no-op when no meter is running.
-`setAttributes` still tags open turn/tool spans when a collector is
-attached.
+## Add domain telemetry
 
-Prefix metric names with your team or agent. First-party names
-(`cursor.token.usage`, `cursor.tool.calls`, `cursor.cost.usage`,
-`agent_sdk.session.count`, `agent_sdk.turn.count`,
-`agent_sdk.subagent.count`, `agent_sdk.http.duration`) and join keys
-(`cursor.conversation.id`, `agent_sdk.session_id`, `agent_sdk.agent`,
-`agent_sdk.turn_id`, `agent_sdk.framework`) are reserved. Custom spans
-are not on this
-surface.
+Use `ctx.host.otel` when your dashboard should answer questions the
+built-in telemetry cannot, such as which incident a turn handled or how
+long approval took. Attributes appear on the active turn and tool
+spans, while counters and histograms give you metrics to graph and
+alert on.
 
 ```ts
 ctx.host.otel.setAttributes({
-  "abc.ticket_id": "INC-123",
-  "abc.queue": "p1",
+  "support.ticket_id": "INC-123",
+  "support.queue": "p1",
 });
-ctx.host.otel.increment("abc.ticket.resolved");
-ctx.host.otel.record("abc.approval.duration_ms", 1420, {
+
+ctx.host.otel.increment("support.ticket.resolved", {
+  outcome: "fixed",
+});
+
+ctx.host.otel.record("support.approval.duration_ms", 1420, {
   outcome: "approved",
 });
 ```
 
-A session-bound host (tools and hooks) adds `cursor.conversation.id`
-and `agent_sdk.agent` for you. Tags merge: later `setAttributes` calls
-paint open spans and later first-party metrics.
-
-## What stays off the OpenTelemetry wire?
+This API is available in tools, hooks, and channel handlers. A
+session-bound context adds `cursor.conversation.id` and
+`agent_sdk.agent` automatically, so custom measurements join the
+first-party telemetry without extra plumbing.
 
-User prompts, tool arguments, tool results, and failure messages are
-omitted by default. Failure spans still record an error status with a
-generic message (`turn failed` / `session failed`).
+Prefix custom names with your team or agent. First-party metric names
+and join keys are reserved, and this surface does not create custom
+spans.
 
-Opt in with `OTEL_LOG_USER_PROMPTS=1` and `OTEL_LOG_TOOL_CONTENT=1`, or
-the matching `logs: { userPrompts, toolContent }` fields on
-`serve({ otel })`. Opted-in strings truncate at 2,048 characters.
+## Choose signals
 
-Deployment URLs from `agent.bound` stay off spans unless
-`toolContent` is on.
+Once export has a destination, traces and metrics are on by default;
+logs remain off until you opt in.
 
-## How does Agent SDK export relate to Cursor enterprise export?
+| Signal | What appears |
+| --- | --- |
+| Traces | HTTP requests, turns, tools, and subagents |
+| Metrics | Token usage, tool calls, cost, and Agent SDK session or turn counts |
+| Logs | Session events, after you enable log export |
 
-[Cursor enterprise OpenTelemetry Export](https://cursor.com/docs/enterprise/opentelemetry-export)
-is the team-admin path. Cursor servers send org-wide metrics and logs
-to a collector you configure in Team Settings.
+The first metrics to look for are `cursor.token.usage`,
+`cursor.tool.calls`, and `cursor.cost.usage`. Configure
+`traces: false`, `metrics: false`, or `logs: true` under
+`serve({ otel })` when you need a different signal mix.
 
-Agent SDK export is the process-local path. The serve process sends
-per-run traces, and optional metrics and logs, to a collector you
-point it at.
+## Control what leaves the process
 
-Point both at the same collector when you want one view. Group on
-`cursor.conversation.id`. Resource defaults (`service.name=cursor`,
-`cursor.entrypoint=sdk_ts`) keep the streams next to each other. The
-[wire reference](https://cursor.com/docs/enterprise/opentelemetry-export/wire)
-lists the shared attribute names.
+User prompts, tool arguments, tool results, and failure text stay off
+the wire by default. You still get trace structure, tool names and
+status, usage metrics, and generic failure status without exporting the
+underlying content.
 
-Evals (`defineEval`) stay the in-product regression check. OpenTelemetry
-is the graph in your observability stack.
+Turn on logs first, then opt into prompt or tool content separately:
 
-## What if another OpenTelemetry SDK is already running?
+```bash
+export OTEL_LOGS_EXPORTER=otlp
+export OTEL_LOG_USER_PROMPTS=1
+export OTEL_LOG_TOOL_CONTENT=1
+```
 
-OTel providers are process-global. If Cursor CLI, an extension host, or
-another library already registered a TracerProvider, MeterProvider, or
-LoggerProvider, Agent SDK reuses it. Run `serve` as its own process
-when the Agent SDK exporters should own the destination.
+`OTEL_LOG_USER_PROMPTS` exports user text. `OTEL_LOG_TOOL_CONTENT`
+exports tool inputs, outputs, and failure details. Enable either only
+when the collector's access and retention policies are appropriate for
+that data.
 
-Two mounts with different authored OTel configs fail at serve start.
-Configure once through `serve({ otel })` or env.
+The same controls are available as
+`logs: { userPrompts, toolContent }` under `serve({ otel })`.
 
-## What's next
+## Related
 
 - [`skills/otel/SKILL.md`](../../skills/otel/SKILL.md): compact
-  env / `serve({ otel })` reference for coding agents
-- [Hooks](../reference/hooks.md): observe the same session event stream
-  in-process
-- [Deployment](../deployment.md): env, secrets, and self-hosting
-- [Cursor enterprise OpenTelemetry Export](https://cursor.com/docs/enterprise/opentelemetry-export)
+  configuration and custom-metric reference for coding agents
+- [Hooks](../reference/hooks.md): emit domain telemetry from session
+  events
+- [Deployment](../deployment.md): set collector endpoints and secrets
+  on hosted or self-hosted agents
+- [Cursor enterprise OpenTelemetry Export](https://cursor.com/docs/enterprise/opentelemetry-export):
+  send organization-wide Cursor telemetry to the same collector