Gemini CLI

Hi - I work on this. Uptake is a steep curve right now, spare a thought for the TPUs today.

Appreciate all the takes so far, the team is reading this thread for feedback. Feel free to pile on with bugs or feature requests we'll all be reading.

Thanks for building this! The tool shows a lot of promise. Coming from Claude Code, the core functionality feels solid - just needs some permission refinements to match enterprise use cases. This is based upon quickly skimming the current code.

High ROI feature requests:

• Pattern-based permissions - Bash(git:) to allow git but not rm, Write(logs/.txt) for path scoping

• CLI permission flags - --allowedTools "Read,Bash(npm test)" --deniedTools "Write" for session overrides

• Allow/deny precedence rules - explicit deny should override general allow (security principle)

• Config file hierarchy - system → user → project precedence for policy enforcement

Medium ROI improvements:

• Command argument filtering - whitelist git commit but not git --exec-path=/bin/sh

• Multiple config formats - support both simple arrays and structured permission objects

• Runtime permission diagnostics - gemini permissions list to debug what's actually enabled

• Environment variable injection - top-level env config for OTEL endpoints, API keys, etc.

The permission engine is really the key piece - once you can express "allow X but not Y within X", it unlocks most advanced use cases. Keep up the great work!

On the one hand, yes this has obviously high immediate value; on the other hand, I can't help but feel like you are giving access to multiple tools that can be used for arbitrary code execution anyway (i.e. running tests, installing dependencies, or running any linter that has a plugin system...), so blacklisting `git --exec-path=/bin/sh` for example is... Misguided? You would have a better time containing the agent in an environment without internet access?