Codex sub-agent does not reuse authenticated CLI session from user shell on Windows PowerShell 7

What version of Codex CLI is running?

codex-cli 0.121.0

What subscription do you have?

pro

Which model were you using?

gpt-5.4

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What terminal emulator and version are you using (if applicable)?

PowerShell 7

What issue are you seeing?

When a Codex sub-agent runs gemini -p "hello!", Gemini CLI does not return the model response. Instead, it stops at this authentication prompt:
Opening authentication page in your browser. Do you want to continue? [Y/n]:
This happens even though the exact same command works correctly when I run it manually in my own PowerShell session.

What steps can reproduce the bug?

1. Start a Codex session where sub-agents are available.
2. Ask Codex to spawn a sub-agent.
3. In the sub-agent, run:

gemini -p "hello!"

1. Observe that the sub-agent does not return a Gemini response and instead shows:

Opening authentication page in your browser. Do you want to continue? [Y/n]:

What is the expected behavior?

If Gemini CLI is already authenticated and working in the user’s local PowerShell environment, a Codex sub-agent should be able to run the same command and return the Gemini response.

If session/auth state cannot be inherited, Codex should at least fail with a clearer explanation of what execution context is missing, instead of appearing to have access to the environment while still triggering a fresh browser-auth flow.

Additional information

OS / shell: Windows PowerShell 7
The same command works when run manually by the user:
gemini -p "hello!"
In the Codex sub-agent environment, the command exits with code 0 but only prints the authentication prompt shown above
The sub-agent was able to access the Gemini config directory:
C:\Users\<username>\.gemini

The sub-agent could list files there, including:
google_accounts.json
oauth_creds.json
state.json
settings.json
installation_id
projects.json

The sub-agent could also resolve PowerShell profile paths normally, including:
C:\Users\<username>\Documents\PowerShell\Microsoft.PowerShell_profile.ps1
This suggests the issue is not basic file access, but that the Codex sub-agent execution context does not fully reuse the same authenticated Gemini CLI session as the user’s interactive shell.