continue
continue copied to clipboard
continuedev
Telemetry sent to posthog even with "allowAnonymousTelemetry: false"
Before submitting your bug report
- [X] I believe this is a bug. I'll try to join the Continue Discord for questions
- [X] I'm not able to find an open issue that reports the same bug
- [X] I've seen the troubleshooting guide on the Continue Docs
Relevant environment info
- OS:RHEL7
- Continue:0.7.64
- IDE:VSCODE
- Model:all
- config.json:
{
"models": [
{
"model": "gpt-4o-mini",
"title": "gpt-4o-mini",
"apiKey": "sk-",
"completionOptions": {},
"provider": "openai"
},
{
"title": "mistral",
"provider": "mistral",
"model": "mistral-small",
"apiKey":"myapikey"
}
],
"slashCommands": redacted
"customCommands": [
{
"name": "test",
"prompt": "Write a comprehensive set of unit tests for the selected code. It should setup, run tests that check for correctness including important edge cases, and teardown. Ensure that the tests are complete and sophisticated. Give the tests just as chat output, don't edit any file.",
"description": "Write unit tests for highlighted code"
}
],
"contextProviders":redacted,
"tabAutocompleteModel": {
"title": "openai autocomplete",
"provider": "openai",
"apiKey": "sk-",
"model": "gpt-4o-mini"
},
"tabAutocompleteOptions": {
"useCopyBuffer": false,
"maxPromptTokens": 400
},
"allowAnonymousTelemetry": false,
"docs": []
}
Description
While trying to get the VScode extention to work on RHEL7 behind a proxy (that's why I use 7.64, 8.xx needs libc CXXABI_1.3.8 not available on my system), I saw errors on console. Remember I have "allowAnonymousTelemetry": false and according to https://github.com/continuedev/continue/issues/1414 it's the telemetry which should be deactivated with this parameter.
So here is the console output:
POST https://app.posthog.com/e/?ip=1&_=1724401619208&ver=1.75.2 net::ERR_FAILED 403 (Forbidden)
[Extension Host] TypeError: fetch failed
at Object.fetch (node:internal/deps/undici/undici:11413:11)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5)
at async Mistral._streamChat (/home/[email protected]/.vscode/extensions/continue.continue-0.7.64-linux-x64/out/extension.js:35185:26)
at async Mistral._streamComplete (/home/[email protected]/.vscode/extensions/continue.continue-0.7.64-linux-x64/out/extension.js:35117:26)
at async Mistral.streamChat (/home/[email protected]/.vscode/extensions/continue.continue-0.7.64-linux-x64/out/extension.js:34493:30)
at async f.value (/home/[email protected]/.vscode/extensions/continue.continue-0.7.64-linux-x64/out/extension.js:54352:28)
So I checked the network tab to see this request:
POST /e/?ip=1&_=1724401619208&ver=1.75.2 HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US
Connection: keep-alive
Content-Length: 3721
Content-Type: application/x-www-form-urlencoded
Host: app.posthog.com
Origin: vscode-webview://0krfondcgektnmfi87mkr15a0d662jtehog5o6t16ot2me042gp6
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Code/1.85.1 Chrome/114.0.5735.289 Electron/25.9.7 Safari/537.36
sec-ch-ua: "Not.A/Brand";v="8", "Chromium";v="114"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Linux"
With a base64 payload containing telemetry usage:
[
{
"uuid": "01917e50-38da-748a-9a60-8d2d4c52c6bb",
"event": "step run",
"properties": {
"$os": "Linux",
"$browser": "Chrome",
"$device_type": "Desktop",
"$current_url": "vscode-webview://0krfondcgektnmfi87mkr15a0d662jtehog5o6t16ot2me042gp6/index.html?id=c6c698e6-6776-4575-9734-0ac0bee38821&origin=d8894425-3e8c-4c6f-ad9a-0fe2f35869aa&swVersion=4&extensionId=Continue.continue&platform=electron&vscode-resource-base-authority=vscode-resource.vscode-cdn.net&parentOrigin=vscode-file%3A%2F%2Fvscode-app&purpose=webviewView",
"$host": "REDACTED",
"$pathname": "/index.html",
"$browser_version": 114,
"$browser_language": "en-US",
"$screen_height": 1080,
"$screen_width": 1920,
"$viewport_height": 895,
"$viewport_width": 311,
"$lib": "web",
"$lib_version": "1.75.2",
"$insert_id": "REDACTED",
"$time": 1724401072.347,
"distinct_id": "REDACTED",
"$device_id": "REDACTED",
"$user_id": "REDACTED",
"$referrer": "$direct",
"$referring_domain": "$direct",
"step_name": "User Input",
"params": {
"user_input": "hello"
},
"token": "REDACTED",
"$session_id": "REDACTED",
"$window_id": "REDACTED,
"$pageview_id": "REDACTED"
},
"offset": 3001
},
{
"uuid": "REDACTED,
"event": "userInput",
"properties": {
"$os": "Linux",
"$browser": "Chrome",
"$device_type": "Desktop",
"$current_url": "vscode-webview://0krfondcgektnmfi87mkr15a0d662jtehog5o6t16ot2me042gp6/index.html?id=c6c698e6-6776-4575-9734-0ac0bee38821&origin=d8894425-3e8c-4c6f-ad9a-0fe2f35869aa&swVersion=4&extensionId=Continue.continue&platform=electron&vscode-resource-base-authority=vscode-resource.vscode-cdn.net&parentOrigin=vscode-file%3A%2F%2Fvscode-app&purpose=webviewView",
"$host": "REDACTED",
"$pathname": "/index.html",
"$browser_version": 114,
"$browser_language": "en-US",
"$screen_height": 1080,
"$screen_width": 1920,
"$viewport_height": 895,
"$viewport_width": 311,
"$lib": "web",
"$lib_version": "1.75.2",
"$insert_id": "REDACTED",
"$time": 1724401072.347,
"distinct_id": "REDACTED",
"$device_id": "01917e4aREDACTED",
"$user_id": "REDACTED",
"$referrer": "$direct",
"$referring_domain": "$direct",
"input": "hello",
"token": "REDACTED",
"$session_id": "REDACTED",
"$window_id": "REDACTED",
"$pageview_id": "REDACTED"
},
"offset": 3001
}
]
So, is sent to posthog all my informations, including my input.
Two questions:
- Is it expected?
- why, on another computer running latest extention (0.9.197), the network tab is not logging the requests anymore?
All these logs and the fact that the newer versions hides the network traffic makes me concerned about the privacy of this extension.
To reproduce
- install extension v0.7.x on vscode
- disable telemetry
- open network tab
- run a query and watch the request being send to posthog
on newer version:
- install latest extension on vscode
- open network tab
- run a query to the LLM, and observe that no network query are shown.
Log output
No response
@Xav-Pe Thank you for bringing this up—privacy is a pretty big deal for us, so definitely want to make sure we get this right.
Is it expected?
No, it is not expected that we would send telemetry when disabled on version 0.7.64, or in any version. Since the beginning of Continue we have had the same allowAnonymousTelemetry configuration option that is intended to stop all requests. That said, we no longer have control over the code that has been published in older versions, and it is possible that there is simply a bug in that version. While this is far from ideal, it's not something we can fix.
As for the fact that your input was sent, this is expected in a few much older versions like 0.7.64, but we do not send any prompts or code in any versions that have been released for at least the last many months.
why, on another computer running latest extention (0.9.197), the network tab is not logging the requests anymore?
Most likely the requests are not being logged because they are not being sent at all. If you have disabled telemetry we would not send anything
I think in order to find a solution the first thing I would try is to double check by reloading the VS Code window after disabling telemetry
Another thing you can try is using the VS Code setting to disable telemetry
Hello, here's the behaviour I've noticed with the latest version 0.8.68 with VSCode.
When the telemetry parameter in the VsCode parameters is enabled or disabled, it does nothing. When this parameter is activated and the option in the user settings page is also activated, the telemetry is sent. But if I then deactivate any parameter or even both the telemetry is still sent. I have to restart VSCode after deactivating the telemetry parameters.
Then if the telemetry parameter is deactivated in the VSCode settings and I try to activate it in the user settings page, the button turns green and then turns red again by itself. But that's still enough to activate and send the telemetry data. I have to disable everything and restart the ide.
I think this functionality needs to be reviewed, because data can be sent when we think telemetry is deactivated.
@Xav-Pe Can you confirm the problem is fixed? Very important issue! Thanks!
While this issue specifically relates to VS Code, I noticed that the same issue is occurring with the latest IntelliJ plugin version.
While this issue specifically relates to VS Code, I noticed that the same issue is occurring with the latest IntelliJ plugin version.
Hi did you find any workaround for this issue?
I've just struck this too using the cli. In Codium, allowAnonymousTelmetry is DISABLED.
The output of the cli is largely unusable because there are tons of these littering it...
Error while flushing PostHog Pxe [PostHogFetchNetworkError]: Network error while fetching PostHog
at N4o (file:///usr/local/lib/node_modules/@continuedev/cli/dist/index.js:832:24603)
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async N4o (file:///usr/local/lib/node_modules/@continuedev/cli/dist/index.js:832:11123)
at async Cur.fetchWithRetry (file:///usr/local/lib/node_modules/@continuedev/cli/dist/index.js:832:24473)
at async Cur._flush (file:///usr/local/lib/node_modules/@continuedev/cli/dist/index.js:832:23781) {
error: TypeError: fetch failed
at node:internal/deps/undici/undici:13510:13
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async N4o (file:///usr/local/lib/node_modules/@continuedev/cli/dist/index.js:832:24510)
at async N4o (file:///usr/local/lib/node_modules/@continuedev/cli/dist/index.js:832:11123)
at async Cur.fetchWithRetry (file:///usr/local/lib/node_modules/@continuedev/cli/dist/index.js:832:24473)
at async Cur._flush (file:///usr/local/lib/node_modules/@continuedev/cli/dist/index.js:832:23781) {
[cause]: Error: connect ECONNREFUSED 0.0.0.0:443
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1637:16) {
errno: -111,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '0.0.0.0',
port: 443
}
},
[cause]: TypeError: fetch failed
at node:internal/deps/undici/undici:13510:13
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async N4o (file:///usr/local/lib/node_modules/@continuedev/cli/dist/index.js:832:24510)
at async N4o (file:///usr/local/lib/node_modules/@continuedev/cli/dist/index.js:832:11123)
at async Cur.fetchWithRetry (file:///usr/local/lib/node_modules/@continuedev/cli/dist/index.js:832:24473)
at async Cur._flush (file:///usr/local/lib/node_modules/@continuedev/cli/dist/index.js:832:23781) {
[cause]: Error: connect ECONNREFUSED 0.0.0.0:443
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1637:16) {
errno: -111,
code: 'ECONNREFUSED',
syscall: 'connect',
address: '0.0.0.0',
port: 443
}
}
Ah, running Continue on the continue repo and asking about this issue some more, I get the answer...
Yes, the Continue CLI is still trying to send telemetry by default. It uses two telemetry systems:
1. OpenTelemetry (OTLP) metrics - Sends detailed metrics about usage, performance, etc., if OTEL environment variables are
configured
2. PostHog analytics - Sends product analytics events directly to PostHog
From the code in extensions/cli/src/telemetry/telemetryService.ts and extensions/cli/src/telemetry/posthogService.ts, telemetry is
enabled unless CONTINUE_CLI_ENABLE_TELEMETRY=0 is set in the environment.
In extensions/cli/src/stream/streamChatResponse.helpers.ts, I can see it explicitly records and sends telemetry data during chat
responses, including API requests, token usage, costs, and tool results.
To disable telemetry, you can set the environment variable:
export CONTINUE_CLI_ENABLE_TELEMETRY=0
This applies to both the OTLP metrics and PostHog analytics. For OTLP metrics, it also requires OTEL configuration to be present to
send data, but PostHog will send by default unless disabled.
Confirmed, this fixes it for me (in the cli, at least).
Would be good to get this useful additional info added to the docs, such as...
- https://docs.continue.dev/customize/telemetry
- https://docs.continue.dev/guides/running-continue-without-internet
Ah, running Continue on the continue repo and asking about this issue some more, I get the answer...
Yes, the Continue CLI is still trying to send telemetry by default. It uses two telemetry systems: 1. OpenTelemetry (OTLP) metrics - Sends detailed metrics about usage, performance, etc., if OTEL environment variables are configured 2. PostHog analytics - Sends product analytics events directly to PostHog From the code in extensions/cli/src/telemetry/telemetryService.ts and extensions/cli/src/telemetry/posthogService.ts, telemetry is enabled unless CONTINUE_CLI_ENABLE_TELEMETRY=0 is set in the environment. In extensions/cli/src/stream/streamChatResponse.helpers.ts, I can see it explicitly records and sends telemetry data during chat responses, including API requests, token usage, costs, and tool results. To disable telemetry, you can set the environment variable: export CONTINUE_CLI_ENABLE_TELEMETRY=0 This applies to both the OTLP metrics and PostHog analytics. For OTLP metrics, it also requires OTEL configuration to be present to send data, but PostHog will send by default unless disabled.Confirmed, this fixes it for me (in the cli, at least).
Would be good to get this useful additional info added to the docs, such as...
- https://docs.continue.dev/customize/telemetry
- https://docs.continue.dev/guides/running-continue-without-internet
Adding CONTINUE_CLI_ENABLE_TELEMETRY=0 as an environment variable didn't seem to make a difference.
┬─[m@F13:~]─[07:35:42 AM]
╰─>$ echo "$CONTINUE_CLI_ENABLE_TELEMETRY" (base)
0
Yet, I still see errors where it tries to reach out to PostHog.
Error while flushing PostHog SMe [PostHogFetchNetworkError]: Network error while fetching PostHog
at BEa (file:///home/matthew/.nodenv/versions/24.8.0/lib/node_modules/@continuedev/cli/dist/index.js:1839:24858)
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async BEa (file:///home/matthew/.nodenv/versions/24.8.0/lib/node_modules/@continuedev/cli/dist/index.js:1839:11378)
at async KSr.fetchWithRetry (file:///home/matthew/.nodenv/versions/24.8.0/lib/node_modules/@continuedev/cli/dist/index.js:1839:24728)
at async KSr._flush (file:///home/matthew/.nodenv/versions/24.8.0/lib/node_modules/@continuedev/cli/dist/index.js:1839:24036) {
error: TypeError: fetch failed
at node:internal/deps/undici/undici:15445:13
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async BEa (file:///home/matthew/.nodenv/versions/24.8.0/lib/node_modules/@continuedev/cli/dist/index.js:1839:24765)
at async BEa (file:///home/matthew/.nodenv/versions/24.8.0/lib/node_modules/@continuedev/cli/dist/index.js:1839:11378)
at async KSr.fetchWithRetry (file:///home/matthew/.nodenv/versions/24.8.0/lib/node_modules/@continuedev/cli/dist/index.js:1839:24728)
at async KSr._flush (file:///home/matthew/.nodenv/versions/24.8.0/lib/node_modules/@continuedev/cli/dist/index.js:1839:24036) {
[cause]: AggregateError [ECONNREFUSED]:
at internalConnectMultiple (node:net:1134:18)
at afterConnectMultiple (node:net:1715:7) {
code: 'ECONNREFUSED',
[errors]: [Array]
}
},
[cause]: TypeError: fetch failed
at node:internal/deps/undici/undici:15445:13
at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
at async BEa (file:///home/matthew/.nodenv/versions/24.8.0/lib/node_modules/@continuedev/cli/dist/index.js:1839:24765)
at async BEa (file:///home/matthew/.nodenv/versions/24.8.0/lib/node_modules/@continuedev/cli/dist/index.js:1839:11378)
at async KSr.fetchWithRetry (file:///home/matthew/.nodenv/versions/24.8.0/lib/node_modules/@continuedev/cli/dist/index.js:1839:24728)
at async KSr._flush (file:///home/matthew/.nodenv/versions/24.8.0/lib/node_modules/@continuedev/cli/dist/index.js:1839:24036) {
[cause]: AggregateError [ECONNREFUSED]:
at internalConnectMultiple (node:net:1134:18)
at afterConnectMultiple (node:net:1715:7) {
code: 'ECONNREFUSED',
[errors]: [Array]
}
}
}
I'm facing the same problem here even if I set CONTINUE_CLI_ENABLE_TELEMETRY to 0, PostHog is fetched. Is there a plan to fix this?
There is clearly something being missed with the telemetry environment variables. https://github.com/continuedev/continue/pull/8328#pullrequestreview-3354871477 states there are two variables. Even with both set to 0, I'm still seeing PostHog network errors.
I've updated https://github.com/continuedev/continue/pull/8328 - hopefully it makes things clearer.