Attempt to send telemetry despite it being turned off.

[Byron]

How to reproduce:

• start a new codegen session
  • This creates a new branch and shows the codegen panel
• type any message and see it fail as Claude isn't setup
• shortly after it will try to send telemetry, probably about the failure, even though my Telemtry is completely turned off

And it's clearly related to the Claude failure.

Expected

It won't attempt to send anything.

[Byron]

Maybe this is a quick fix for @Caleb-T-Owens.

[Caleb-T-Owens]

How strange. This does nothing different compared to the rest of the app. I'll look into this first thing today

[Byron]

Thanks so much 🙏!
On the bright side, the data stays in the EU 😁.

[mtsgrd]

I just had a quick look at this, couldn't find any smoking gun.. looks like both front end and back end verify appMetricsEnabled is set to true. Could you double check the ~/Library/Application\ Support/com.gitbutler.app/settings.json file to see that it matches the UI?

[mtsgrd]

One thing I did notice, is that we use a property called appAnalyticsConfirmed in the front end that prevents any analytics until confirmed.. because crates/but-settings/assets/defaults.jsonc defaults appMetricsEnabled to true. This does not exist on TelemetrySettings, but it is set in my settings file.

{
  "appErrorReportingEnabled": false,
  "appAnalyticsConfirmed": true,
  "appMetricsEnabled": true
}

[nshcr]

Screen.Recording.2026-01-21.at.20.11.32.mov

Providing some network capture evidence - this is astonishing.

➜  ~ cat Library/Application\ Support/com.gitbutler.app/settings.json 
{
  "appMetricsEnabled": false,
  "appErrorReportingEnabled": false,
  "appAnalyticsConfirmed": true
}

[mtsgrd]

@nshcr thanks for helping investigate this, we'll want to push a fix asap. While you have that setup, could you confirm if you see any requests in the network tab of the developer tools?

[nshcr]

@mtsgrd No, the network requests shown in the devtools are all IPC requests.
The clients that actually send telemetry data are gitbutler-tauri and but (see the video).

[mtsgrd]

Thanks for confirming. I was just wondering if gitbutler-tauri could be http requests from the webview. My current suspicion is that this is related to app settings, I'll have an update shortly.

[mtsgrd]

@Byron I think I found the issue - we are using different settings for the back end. I'll try and have a fix ready by eod.

[krlvi]

As we are working to fix this, I am happy to share that this buggy behavior is quite limited in the conditions that trigger it.

For the bug to be triggered, telemetry has to have been enabled at some point in the past at least once. Fix with propagating the settings is incoming

[nshcr]

This doesn't really seem like something to be glad about, because telemetry is enabled by default on a fresh install, so basically every user meets that prerequisite.

I also just noticed that in fact all but commands send telemetry regardless of the telemetry toggle state - which is kind of crazy.

Edit:

It also disregards the requirement for anonymous data collection, which should be controlled by app_non_anon_metrics_enabled, the but command does not check it at all.

gitbutler/crates/but/src/utils/metrics.rs

Lines 310 to 324 in 29eecac

	fn do_capture(
	client: &Client,
	event: Event,
	app_settings: &AppSettings,
	) -> impl Future<Output = Result<(), posthog_rs::Error>> {
	let mut posthog_event = if let Some(id) = app_settings.telemetry.app_distinct_id.clone() {
	posthog_rs::Event::new(event.event_name.to_string(), id.clone())
	} else {
	posthog_rs::Event::new_anon(event.event_name.to_string())
	};
	for (key, prop) in event.props {
	let _ = posthog_event.insert_prop(key, prop);
	}
	client.capture(posthog_event)
	}