What happened?
The Gemini command-line tool (gemini) on macOS prompts for user login when started in Agent Communication Protocol (--experimental-acp) mode from a Python subprocess, even when valid cached credentials exist. The same
command, when run directly from an interactive terminal, correctly uses the cached credentials without a login prompt.
This behavior prevents the use of the gemini tool in automated Python scripts that rely on the acp mode and the standard OAuth2 authentication flow.
Expected Behavior:
When launched as a subprocess from a Python script, gemini --experimental-acp should detect and use the valid cached credentials in ~/.gemini/google_accounts.json without prompting for an interactive login, just as it
does when run from the terminal.
Actual Behavior:
When launched from a Python script, gemini --experimental-acp ignores the cached credentials and prompts for a new interactive login.
Steps to Reproduce:
-
Confirm credentials in terminal:
- Log in to the Gemini CLI to create a cached credential file.
- Run gemini --experimental-acp directly in your terminal.
- Observe that it starts without prompting for a login.
-
Reproduce the issue in Python:
- Save the following Python script as repro_bug.py:
1 import asyncio
2 import os
3 import sys
4
5 async def main():
6 print("Starting 'gemini --experimental-acp' from a Python script...")
7 env = os.environ.copy()
8 process = await asyncio.create_subprocess_shell(
9 'gemini --experimental-acp',
10 env=env,
11 stdout=asyncio.subprocess.PIPE,
12 stderr=sys.stderr # Pipe stderr to see the login prompt
13 )
14 print("Process started. Waiting for output...")
15 await process.wait()
16
17 if name == "main":
18 asyncio.run(main())
* Run the script from your terminal: python3 repro_bug.py
* Observe that the script's output now includes the interactive login prompt from the Gemini CLI.
Environment:
Analysis/Investigation:
During our debugging session, we confirmed the following:
- The HOME environment variable is correctly set and accessible within the Python script.
- The Python script explicitly passes a copy of the environment to the asyncio.create_subprocess_shell function.
- The issue is not related to file permissions or macOS extended attributes on the credential file.
- A pre-authentication step (running a simple gemini command from the script) was successful, but it did not prevent the subsequent gemini --experimental-acp command from prompting for a login.
This investigation strongly suggests that the gemini CLI, when in acp mode, behaves differently when it detects it is being run as a non-interactive subprocess from a Python script, and it fails to correctly locate or
use the cached credentials in this scenario.
Suggested Solution/Workaround:
The only reliable workaround at the moment is to use API key-based authentication, which bypasses the interactive login flow.
What did you expect to happen?
When launched as a subprocess from a Python script, gemini --experimental-acp should detect and use the valid cached credentials in ~/.gemini/google_accounts.json without prompting for an interactive login, just as it
does when run from the terminal.
Client information
Client Information
Run gemini to enter the interactive CLI, then run the /about command.
> /about
# paste output here
Login information
No response
Anything else we need to know?
No response
What happened?
The Gemini command-line tool (gemini) on macOS prompts for user login when started in Agent Communication Protocol (--experimental-acp) mode from a Python subprocess, even when valid cached credentials exist. The same
command, when run directly from an interactive terminal, correctly uses the cached credentials without a login prompt.
This behavior prevents the use of the gemini tool in automated Python scripts that rely on the acp mode and the standard OAuth2 authentication flow.
Expected Behavior:
When launched as a subprocess from a Python script, gemini --experimental-acp should detect and use the valid cached credentials in ~/.gemini/google_accounts.json without prompting for an interactive login, just as it
does when run from the terminal.
Actual Behavior:
When launched from a Python script, gemini --experimental-acp ignores the cached credentials and prompts for a new interactive login.
Steps to Reproduce:
Confirm credentials in terminal:
Reproduce the issue in Python:
10 env=env,
11 stdout=asyncio.subprocess.PIPE,
12 stderr=sys.stderr # Pipe stderr to see the login prompt
13 )
14 print("Process started. Waiting for output...")
15 await process.wait()
16
17 if name == "main":
18 asyncio.run(main())
* Run the script from your terminal: python3 repro_bug.py
* Observe that the script's output now includes the interactive login prompt from the Gemini CLI.
Environment:
Analysis/Investigation:
During our debugging session, we confirmed the following:
This investigation strongly suggests that the gemini CLI, when in acp mode, behaves differently when it detects it is being run as a non-interactive subprocess from a Python script, and it fails to correctly locate or
use the cached credentials in this scenario.
Suggested Solution/Workaround:
The only reliable workaround at the moment is to use API key-based authentication, which bypasses the interactive login flow.
What did you expect to happen?
When launched as a subprocess from a Python script, gemini --experimental-acp should detect and use the valid cached credentials in ~/.gemini/google_accounts.json without prompting for an interactive login, just as it
does when run from the terminal.
Client information
Client Information
Run
geminito enter the interactive CLI, then run the/aboutcommand.Login information
No response
Anything else we need to know?
No response