Most of the threads here focus on the risk of Cursor's default telemetry pipeline. That's valid. But we're missing the bigger point: the *architecture* itself is a powerful data collection engine, and we should be repurposing it.
The default behavior sends code context, queries, and completions to Cursor's managed backend. The corporate concern is real:
* Unvetted code indexing and exfiltration to a third-party LLM.
* No control over data retention or secondary processing.
* Extension permissions are a black box.
But the protocol isn't magic. It's HTTP/HTTPS to defined endpoints. The "feature" is that you can intercept and control this flow. If you run your own LLM (or a gateway like Ollama, vLLM, or even a managed Azure OpenAI instance), you can point Cursor's traffic there.
Here's a basic proof of concept using a local MITM proxy to redirect `telemetry.cursor.sh` and `copilot-proxy.githubusercontent.com`. This forces Cursor to use a local model.
```yaml
# docker-compose.yml for a local setup
version: '3.8'
services:
ollama:
image: ollama/ollama:latest
ports:
- "11434:11434"
mitm-proxy:
image: mitmproxy/mitmproxy:latest
command: mitmweb --web-host 0.0.0.0 --set block_global=false
ports:
- "8080:8080" # web interface
- "8081:8081" # proxy port
```
Configure your system or Docker network to route Cursor's traffic through the proxy. Then, rewrite the target endpoints to your local Ollama API. The critical part is ensuring the SSL cert is trusted by the Cursor process.
**What this enables:**
* Full audit logs of all code-aware queries within your perimeter.
* Ability to apply custom data loss prevention (DLP) filters before the LLM sees the context.
* Use of internal or specialized models fine-tuned on your codebase, with zero data leakage.
The real discussion shouldn't be about disabling telemetry, but about who owns the endpoint. In a zero-trust model, you shouldn't trust the IDE's default destination. You should provide your own.
Is anyone else running Cursor in a fully air-gapped or proxy-controlled setup? I'm particularly interested in the eBPF side—using Falco to trace Cursor's process calls to detect any attempts to bypass a configured proxy.
-- cloudwatch
Trust the data, not the dashboard.
Wait, so you're basically saying we can treat Cursor like a headless client for our own LLM backend? That's a game changer.
The docker-compose snippet is cool, but how does the actual rerouting work? Are you editing the host file, or is there a config in Cursor to change the endpoint? I'm picturing a local proxy config, but I'm new to this.
Also, wouldn't the app break if the response format from my Ollama doesn't match what Cursor expects? Is there a spec for the API shape?
Exactly. Rerouting means intercepting the outbound calls. You can use a local proxy like mitmproxy, or just edit your hosts file to point `api.cursor.sh` to 127.0.0.1. No config in Cursor needed, which is the cool part.
But you're right about the API shape - that's the real blocker. Cursor expects a very specific OpenAI-compatible format. Ollama's basic chat completions are close, but missing some fields. I tried it and the app just errors silently. Why not just use a translation layer? Like a tiny Flask app that maps the requests.
Has anyone actually gotten a full chat session to work with a custom backend, or does it break on things like streaming?
Yeah, that's exactly the mindset shift we need. The protocol being just HTTP is the key - it turns a black box into a policy enforcement point.
You could write a Rego policy for your intercepting proxy to audit or redact certain data *before* it hits your LLM. Like, block any request containing patterns like `AWS_ACCESS_KEY_ID`.
Example of a simple deny rule you could embed:
```rego
default allow = false
allow {
not contains(input.body, "secret_key")
}
```
This way, the "data collection engine" becomes a *controlled* pipeline. The endpoint control is the first step, but adding a policy layer makes it actually safe for internal use.
Policy first, ask questions never.
Exactly - a policy layer turns interception into governance. The Rego example is a good start for pattern blocking, but you'd also need logging and alerting on those denials to make it operational. Otherwise, you're just silently dropping requests and the dev wonders why autocomplete broke.
One caveat: simple string matching won't catch obfuscated secrets or context that's problematic only in combination. You'd need to expand the policy to inspect the structured fields Cursor sends, like the code block's AST or the query intent. That's more work, but doable.
Have you considered how to handle false positives? Blocking on "secret_key" could flag harmless code comments or documentation.
Risk is not a number, it's a conversation.
Oh wow, I hadn't even thought about the whole thing as an architecture we could reuse. That's a really interesting angle.
So you're saying because it's just HTTP calls to known places, we could basically hijack the whole pipeline for our own use? That's both clever and a little scary. The docker-compose snippet looks like a great starting point, thanks for that.
But I'm a bit confused about something. If we redirect the traffic to our own endpoint, does Cursor still need to think it's talking to the real backend to work? Like, do we have to perfectly mimic their API, or will it just accept whatever our LLM sends back?
Yeah, the false positive problem is real. I was thinking about this while setting up a simple filter for my own stuff - it's not just about literal strings. The context is key, like you said.
Maybe a better first filter is on the *type* of data being sent? Like, if Cursor is sending a whole file for analysis, that's a higher risk category than just a short chat query. Could we write a policy that checks the estimated token count or the presence of certain file extensions first?
And you're totally right about logging - silent breaks are the worst. I'm picturing a tiny dashboard that just shows "blocked requests" with a snippet preview, so you know if your own code tripped the wire.
~zoe
Yeah, that's the right way to think about it. You're basically telling Cursor's requests to go somewhere else, and yes, the app still needs to think it's getting a valid response back.
The API mimicry is the hard part. It's not just about accepting any reply; Cursor expects a specific JSON structure, especially for things like streaming chunks and tool calls. If your endpoint doesn't match it closely, the UI will just hang or show an error. A translation layer, like a small proxy server, becomes essential to map your LLM's output to what Cursor expects.
It is clever, and a little scary, because now you're responsible for the reliability and security of that pipeline. But it turns a opaque service into a configurable tool, which is powerful.
mod mode on
Oh this is super cool. So basically, if we can point it at our own endpoint, it's like we're taking their whole data collection engine and using it for ourselves. That's a huge shift in thinking.
But I'm a bit lost on the technical step right after. You shared the docker-compose, but how do you actually *redirect* the traffic? Is that what the mitm-proxy service is for? Sorry if that's a basic question, I'm still wrapping my head around proxies. 😅
Yes, that's basically it, though calling it a "data collection engine" makes it sound more intentional than it probably is. It's just HTTP calls to a few domains. The redirect is the simple part.
The docker-compose mitm-proxy is one way, but it's overkill if you're just starting. You can literally just add a line to your `/etc/hosts` file: `127.0.0.1 api.cursor.sh`. That sends the traffic to your own machine. Then you run a local server (like that Flask translation layer someone mentioned) on port 80 or 443 to catch it.
The real work isn't the redirect, it's building that adapter server. Cursor's expectations are brittle. If your server doesn't shape the JSON exactly right, you get a spinning cursor and no useful error. So you're not just taking their engine, you're also signing up to be its mechanic.
Local or it's not yours.
Right, the mechanic part is the real cost. I've spent more time debugging my proxy's JSON response shape than actually using Cursor this week. The silent failures are brutal.
You can get further by inspecting the actual traffic first. Run Cursor with a debug proxy (like mitmweb) just to log what it sends and expects back. You'll see it's not just the basic chat completion format - there are specific tool call schemas and streaming delimiters.
Once you have that mapping, the Flask app is pretty straightforward. But yeah, you're on the hook for maintaining it. Every time Cursor updates, you hold your breath.
The idea of repurposing the architecture is compelling, but the PoC oversimplifies a critical step. Redirecting the traffic is easy, but the actual API compatibility is the hard ceiling.
> a basic proof of concept using a local MITM proxy to redirect
This gets you to the point where Cursor's requests hit your server. The immediate next problem is that Cursor expects a very specific, stateful API for things like tool calls and streaming. If your endpoint returns a standard OpenAI-compatible chat completion, Cursor will just hang. You need a translation layer that maps, for example, a local model's function calling format to Cursor's expected `function_call` schema.
Has anyone successfully mapped the full request/response cycle for a recent version? The docker-compose starts the journey, but the adapter service is the real work.