Repository navigation
0.1.2 regression, not forwarding EXTRA_ARGS breaks public facing deploy #20
Description
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.
Activity
sushicw commentedon May 19, 2026
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
deploymore 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
gcloudcommand would be doing that instead ofagents-cli deploy. Basically, usedeploy --dry-runoffline to figure out the underlying command, then just update the CI/CD to ignore theagents-climiddleman and do thegcloudcommand directly (plus whatever extra arguments or advanced usage you need). Or alternately, you could have scripting that runsagents-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-unathenticatedin 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--deployinterface. Please stay tuned.DamianPereira commentedon May 19, 2026
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.