0.1.2 regression, not forwarding EXTRA_ARGS breaks public facing deploy

[DamianPereira]

What happened?

Hi! I have an adk agent deployed into a public facing endpoint, with a middleware providing jwt based auth for user resources.

This is intended to be a production agent facing real end users, not an internal tool used by employees or depending on google auth. agents-cli 0.1.1 worked fine for this, by allowing me to use --allow-unauthenticated (authentication was happening in the middleware layer).

skills and help say use --dry-run (or -n) to print the full gcloud command, copy it, and add additional arguments as needed.. But this is part of CI/CD systems, I can not stop, edit the command, and send it again. A window of not being reachable is also not acceptable.

Why was this feature removed? It breaks agents-cli for our usecase, with no apparent benefit.

Steps to Reproduce

run agents-cli deploy --project some-project --allow-unauthenticated

What did you expect to happen?

agent deploys and endpoint is publicly reachable (allUsers group has invoke role)

Client information

Client Information

Not relevant, I have 0.1.1 locally, but 0.1.2 breaks our workflows.

Command Output / Logs

agents-cli v0.1.3
Usage: google-agents-cli deploy [OPTIONS]
Try 'google-agents-cli deploy --help' for help.

Error: No such option '--allow-unauthenticated'.

Anything else we need to know?

There seems to be close to 0 docs on how to do a public facing production ready agent. I had to drop agent engine since there was no way of adding ag-ui-adk middleware to it in order to use frontend agent ui tools.

[sushicw]

Thank you for writing!

Some background on this change: we wanted to avoid the pass-through arguments because it couples the agents-cli interface with the underlying implementation, meaning you have to know what internal thing is being called in order to know what extra args are valid to include, and it makes it difficult for us to maintain as those internal args (which we don't control) may change, or where we may want to use different underlying commands for different use-cases. Removing the pass-through EXTRA_ARGS brought deploy more in line with other commands.

Full transparency here: we did recognize this was not backwards compatible, but hoped that we could squeeze the change in before anyone was actually depending on the pass-through behavior. It looks like that gambit did not pay off. Sincere apologies for the trouble this has caused you!

The recommendation in the skills to use the underlying gcloud command would be doing that instead of agents-cli deploy. Basically, use deploy --dry-run offline to figure out the underlying command, then just update the CI/CD to ignore the agents-cli middleman and do the gcloud command directly (plus whatever extra arguments or advanced usage you need). Or alternately, you could have scripting that runs agents-cli deploy --dry-run, parses out the gcloud command, and then runs that with extra args appended. I wouldn't be happy needing to resort to that kind of workaround either, though.

All that said: this is useful feedback that --allow-unathenticated in particular is a useful thing for you, and one thing we can do is examine if it would make sense to promote it to be part of the --deploy interface. Please stay tuned.

[DamianPereira]

Thanks! Yes that's what we ended up doing, fall back on gcloud. Some general advice or docs on how to do auth would be awesome, it looks like agents-cli is very targeted to intranet/gemini enterprise agents, instead of public facing auth-gated agents. Or at least there are some gaps in the docs/examples.

If it happens with --alllow-unauthenticated or some other flag, or any kind of change in adk/agents-cli/etc that's out of my hands, I'd love a recommended secure "this is how you do auth for an agent" pattern, even if it means restructuring our current solutions.