CORS Issue with Custom Anthropic keys.

[rayansostenes]

Version

0.15.17

Operating System

macOS

Distribution Method

dmg (Mac OS - Apple Silicon)

Describe the issue

Using my organization key for Anthropic does not work, it appears to be something related to CORS.

Debug info:
Model kind: anthropic, Using GB API: false, Config valid: true, Testing commit message
generation, Error: 401

{
  "type": "error",
  "error": {
    "type": "authentication_error",
    "message": "CORS requests are not allowed for this Organization because of custom retention settings. If you believe this in error, contact support at https://support.anthropic.com/."
  },
  "request_id": "req_011CSk4dbcNydcnGzVR83B4R"
}

How to reproduce (Optional)

No response

Expected behavior (Optional)

No response

Relevant log output (Optional)

[Byron]

Thanks for reporting!

Does this issue resolve for you after having taken a look at the CORS related support document?

The gist is that ~/Library/Application\ Support/gitbutler/settings.json needs an entry like this:

{
  "extraCsp": {
    "hosts": ["https://subdomain.example.com", "http://another-subdomain.example.com"]
  }
}

The changes will take effect the next time you start GitButler.

Thanks again

[rayansostenes]

@Byron I don't think it does, the error comes from the Anthropic server is not a client error. The API Key provided by my company has a Zero data retention policy with Anthropic (Which makes sense in our case), but in this case the header anthropic-dangerous-direct-browser-access: true does not work.

I think I'm gonna try to make a small proxy server running on localhost, and use Anthropic's OpenAI compatibility.

[Byron]

I see, thanks for sharing!

In case you have a beefy developer machine, you could consider running a local model as well. They work pretty well for the task, too, from all I can tell (using Qwen3 30B or Gemma3 27B).

[avadhanij]

Running into this issue as well. It would be good to have a documented approach to dealing with it.

[Byron]

I think my understanding about this issue changed. By the looks of it, we'd have to provide an option that alters the header GitButler sends. But while that's done from the frontend, the browser process will never allow full control.

Thus I think this will be fixed once this functionality is implemented in the backend, which is planned but not underway yet.

CC @krlvi to say that the backend implementation would probably give us higher success rates for connecting to these APIs.

[avadhanij]

Curious about what the frontend/backend aspect of this app. I am a new user and I was surprised to see the token fail this way since I am able to use tokens like this one, say in Zed (Editor) which also has a similar bring your own token approach.

[krlvi]

Curious about what the frontend/backend aspect of this app. I am a new user and I was surprised to see the token fail this way since I am able to use tokens like this one, say in Zed (Editor) which also has a similar bring your own token approach.

Hi Avadhani! GitButler uses Tauri which allows us to build all the UI portions using web tech (in particular Typescript in a Svelte single page app) which interacts with the "backend" which is written in rust over a local IPC api.

The "backend" is responsible for all the version control internals etc. and more recently the gitbutler CLI uses the same plumbing code as well.

Back to the UI - it is rendered in the OS-native webview (webkit on OSX) and there it is subject to the usual CORS constraints.

Currently, the particular functionality around generating commit messages and branch names is implemented in typescript, and it appears that through to an API change on Anthropic side, they no longer permit API access from browsers that are not on one of their domains.

Moving the implementation of this outside of typescript would mitigate this issue (and would also be nice for making the functionality available on the CLI), but it is somewhat time consuming and we have not had the chance to take care of this yet I am afraid

[avadhanij]

Appreciate the explanation and it makes sense. My only concern at this point is does the GitButler token itself have zero retention policy set up?

E.g.: if I ask it to craft a commit message, it's reading all the diff code and using OpenAI/Anthropic API to create the message, but there is some data sharing happening there, correct?

[krlvi]

@avadhanij thanks for the question. The GitButler token option is basically there for convenience for users who don't have or prefer not setup their own keys with a provider (or locally hosted model). On the GitButler's side, there is no retention of the input of any kind (i.e. it's just a proxy). There is just a rate limit per session, to guard against abuse.

On the OpenAI and Anthropic side of things, it would be impossible for me to confirm but both claim that there is no data retention. In the OpenAI console under data control / data retention everything is disabled. And Anthropic, in their Commercial Terms of Service specify that they dont retain the input.

Because this of course uses third party infrastructure, the most private way to access this functionality is via the Ollama or LM Studio in the app + a self hosted model.