You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
agents-cli run passes entire project root contents as positional arguments to adk web, causing startup failure #38
agents-cli version: v0.5.0
OS: Windows
Shell: PowerShell
Package manager: uv (project includes uv.lock)
Project structure at root: app/, Dockerfile, GEMINI.md, pyproject.toml, README.md, tests/, uv.lock
Summary
Running agents-cli run fails to start the local playground server. The underlying adk web invocation receives every file and folder in the project root as separate positional arguments, instead of receiving the single agent directory name (app). This causes adk web's argument parser to reject the call.
Steps to Reproduce
Create or use an ADK agent project with the following at the root: app/, Dockerfile, GEMINI.md, pyproject.toml, README.md, tests/, uv.lock.
From the project root, run:
agents-cli run "How are you?"
Observe the command times out attempting to start the local server, then fails.
Actual Behavior
Error: Local server did not start within 30s.
Check logs: .google-agents-cli/run_server.log
Checking the log file shows the actual root cause:
Usage: adk web [OPTIONS] [AGENTS_DIR]
Try 'adk web --help' for help.
Error: Got unexpected extra arguments (app Dockerfile GEMINI.md pyproject.toml README.md tests uv.lock)
agents-cli v0.5.0
Error: Failed to start playground (exit code 2)
What did you expect to happen?
Expected Behavior
agents-cli run should invoke adk web with only the correct agent directory (e.g. adk web app), not every file/folder in the project root.
Workaround Confirmed
Bypassing agents-cli and invoking adk web directly works correctly:
uv run adk web app
This starts the server successfully:
INFO: Application startup complete.
INFO: Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
This confirms the issue is isolated to how agents-cli run constructs its internal call to adk web — the local Python/uv environment, dependencies, and API credentials are all functioning correctly.
Client information
Client Information
Run agents-cli info to output debugging information about your client.
Command Output / Logs
No response
Anything else we need to know?
Suggested Fix
When agents-cli run builds the adk web command, it should pass only the resolved agent subdirectory (likely app, or whatever is configured as the agent directory for the project) as the single positional argument, rather than expanding/passing all root-level files and folders.
Ensure no persistent playground or local servers are running.
In the project root on Windows, run agents-cli run "Hello" to trigger a one-off query.
Actual Output
agents-cli v0.5.0
Error: Local server did not start within 30s.
Check logs: .google-agents-cli/run_server.log
Cause
_local_server.py attempts to spawn a detached background server process using start_new_session=True in subprocess.Popen. On Windows, launching Python/uv detached without a console window causes a silent startup crash (often status 0xc0000142), preventing the port from ever binding.
Expected Output
A temporary local server starts, queries the agent, prints the response in the console, and gracefully shuts down.
Temporary Workaround
Keep the server running persistently in a separate terminal with agents-cli playground, and run CLI queries by pointing to it directly:
agents-cli run "Hello"--url http://127.0.0.1:8080--mode adk
```/
agents-cli playground on other terminal didn't work with error Error: Got unexpected extra arguments (app Dockerfile GEMINI.md pyproject.toml README.md tests uv.lock).
Note that this is still a bit of a workaround, since the underlying adk web bug is still there: tracked separately at google/adk-python#6166. But it should get things working on Windows machines again.
Activity
casperlim99 commentedon Jun 20, 2026
Yea I have the same issue as well for Windows.
How to Recreate
agents-cli run "Hello"to trigger a one-off query.Actual Output
Cause
_local_server.pyattempts to spawn a detached background server process usingstart_new_session=Trueinsubprocess.Popen. On Windows, launching Python/uv detached without a console window causes a silent startup crash (often status0xc0000142), preventing the port from ever binding.Expected Output
A temporary local server starts, queries the agent, prints the response in the console, and gracefully shuts down.
Temporary Workaround
Keep the server running persistently in a separate terminal with
agents-cli playground, and run CLI queries by pointing to it directly:Subarna578 commentedon Jun 21, 2026
Hey @casperlim99 , is this issue same as reported here? #40
casperlim99 commentedon Jun 21, 2026
@Subarna578 Yes, same issue. Test if my workaround works for you.
Subarna578 commentedon Jun 21, 2026
agents-cli playground on other terminal didn't work with error Error: Got unexpected extra arguments (app Dockerfile GEMINI.md pyproject.toml README.md tests uv.lock).
So, I tried to use the workaround by running
uv run adk web . --host 127.0.0.1 --port 8080 --allow_origins "http://127.0.0.1:8080"
then from next terminal,
agents-cli run "Hello" --url http://127.0.0.1:8080 --mode adk
casperlim99 commentedon Jun 21, 2026
The agent-cli playground issue should be related to this #34 , seems to be an issue with the ADK. The workaround mentioned there works for me.
sushicw commentedon Jun 22, 2026
Fix released in https://github.com/google/agents-cli/releases/tag/v0.5.1.
Note that this is still a bit of a workaround, since the underlying
adk webbug is still there: tracked separately at google/adk-python#6166. But it should get things working on Windows machines again.