[fipro78]

#171

What it does

This PR adds Antigravity CLI as supported tool profile.

How to test

Build locally and then start via enclave --tool antigravity

Either follow the OAuth flow to authenticate with your Google account, or set the environment variables GEMINI_API_KEY and optional GOOGLE_GEMINI_BASE_URL if you for example use a LiteLLM proxy for testing. The authorization via API key is described here: https://antigravity.google/docs/install/?tab=cli#using-a-gemini-api-key

Follow-ups

I tested using the OAuth authorization as well as the usage of a custom endpoint via LiteLLM proxy according to https://antigravity.google/docs/install/?tab=cli#using-a-gemini-api-key
Similar to the issue fixed via #143 I get the following error when Antigravity tries to connect to the LiteLLM:

⚠ agent executor error: generating and executing: Error 401, Message: {"error":{"message":"LiteLLM Virtual Key expected. Received=ENCL****5d4a, expected to start with 'sk-
'.","type":"auth_error","param":"None","code":"401"}}, Status: 401 Unauthorized, Details: []

I tried to workaround via this configuration_

{
  "host_config": "passthrough",
  "tool_overrides": {
	"antigravity": {
      "pass_env": [
		"GOOGLE_GEMINI_BASE_URL", 
		"GEMINI_API_KEY" 
	  ],
	  "no_api_key": true
    }
  },
  "allow_domains": [
	"<litellm-url>", 
  ],
  "allow_all_network": false
}

With this I am able to access the LiteLLM via Antigravity. If I got it right, the no_api_key=true setting avoids the usage of the ENCLAVE_SECRET_<hex> placeholder for the API key and the API key is in the container like it is in the host.
Actually I am not sure where the check really happens or when the transformation should happen to avoid this. But compared to #143 it doesn't make sense to add this to the tool spec.yaml as it is a special handling for the usage of a LiteLLM proxy (and maybe even other proxies?) and not for Antigravity itself.

It would be great if anybody could give me a hint how this can be solved in a better way, where the enclave secret mechanism still can be used.

Breaking changes

• This PR introduces breaking changes and has been coordinated with maintainers.

Review checklist

• As an author, I have thoroughly tested my changes and carefully followed the contribution guidelines.

[tortmayr]

Antigravity cli is already available in our extension repo: https://github.com/eclipse-enclave/enclave-extensions

@xai What is the general strategy regarding builtin-extensions vs extensions in the extension repository?
How do we decide where an extension/tool should live?

[xai]

@fipro78 Thanks for putting this together!

You couldn't have known about the extensions repo because our docs don't mention it yet. Our fault, sorry about that. We'll do something about that.

You can install the extension like this: enclave tools add eclipse-enclave/enclave-extensions --name antigravity and then you can use enclave --tool antigravity.

I see that your profile has some things we do not have yet (AGY_CLI_DISABLE_AUTO_UPDATE, auth session check, the statePaths list, and the enclave-help skill), so it would be great to have a PR against main of https://github.com/eclipse-enclave/enclave-extensions that adds everything you need.

Regarding LiteLLM we could use a mechanism introduced by #35, where serviceAuth.<id>.hostsFromCredential lets one variable select the host a credential is released to. For antigravity, it might look a little like this:

credentials:
  sources:
    gemini-api-key: { env: [GEMINI_API_KEY] }
    gemini-base-url: { env: [GOOGLE_GEMINI_BASE_URL], apiKey: false }
network:
  serviceAuth:
    gemini-api-key: { headerName: x-goog-api-key, hostsFromCredential: gemini-base-url }

Then you could set GOOGLE_GEMINI_BASE_URL to your custom endpoint and hopefully it works.

@tortmayr Yes, this is an important question. I think most extensions should start in the extensions repo. If we feel something is used a lot and seems mature, we can always promote it to the core repo later. For copilot, we wanted it to be part of core, because I think that many companies allow employees to use the copilot tool. If there is evidence that this is also true for antigravity, we could discuss promoting it.

[fipro78]

@xai
I created eclipse-enclave/enclave-extensions#7

I tested your suggestion, and it worked in my local tests.

About the repo where it should be. Well, I have no strong feelings about this, but I wonder why pi and mistral-vibe are part of the core, and something like Antigravity is in the extensions repo. Don't really get the weights for the decision.

[xai]

@xai
I created eclipse-enclave/enclave-extensions#7

I tested your suggestion, and it worked in my local tests.

About the repo where it should be. Well, I have no strong feelings about this, but I wonder why pi and mistral-vibe are part of the core, and something like Antigravity is in the extensions repo. Don't really get the weights for the decision.

Thanks! I'll have a look!

I admit, I don't have a really good answer. One point is that both are European software projects and I felt they are a good fit to complement the two big American ones (claude and codex). As for pi, it is pretty well tested in enclave, because I use it a lot myself since we started Enclave. And it makes it super easy to use different providers (which opencode does too).
The test matrix is the second point. Testing and reviewing is clearly the bottleneck and that is never going to change. I usually test all core tools in at least two of the three backends for anything that touches critical parts of the gateway, the auth or state dirs or the Dockerfile or an entrypoint.

I will try antigravity a bit more often to get a better feel for it and to understand how well it currently works in enclave. You are right that the only Google product in the field being extension-only is hard to justify. If it works really well, I wouldn't object to promoting it to core in a while.

[tortmayr]

I think we need to have a discussion with the team regarding the best strategy for this.
We need a clear strategy for core vs. extension repo both for tools and features.
In general, I'm wondering whether we even want to have too many core extensions or if we should rather focus on a sensible small core set and the rest is user configurable/installable via the extension repo.

Independent of that we probably also need a mechanism to disable tools that are shipped by default,
which is currently not possible.
The impact is rather slim

• tools that a user don't wants/needs are still exposed via CLI
• Mechanism like update all tools have an overhead and also update unneeded/wanted tools

Until this is discussion is resolved, I would suggest to continue the agy integration in the extension repository.