feat: add --reload_agents flag to watch agent files for changes

[nuthalapativarun]

Please ensure you have read the contribution guide before creating a pull request.

Link to Issue or Description of Change

• Closes: Support for reloading agents on file change #196

Testing Plan

Unit Tests:

• I have added or updated unit tests for my change.
• All unit tests pass locally.

Test Files  112 passed (112)
Tests  1248 passed (1248)

Manual End-to-End (E2E) Tests:

1. Start the dev server with npx adk web --reload_agents my-agents/
2. Edit an agent file (e.g. change the instruction string)
3. Send a new message — the updated agent is loaded automatically without restarting the server
4. Console shows: [AgentLoader] Detected change in agent.ts, reloading agents...

Without --reload_agents (default false), behaviour is unchanged — agents are loaded once at startup and cached for the process lifetime.

Checklist

• I have read the CONTRIBUTING.md document.
• I have performed a self-review of my own code.
• I have commented my code, particularly in hard-to-understand areas.
• I have added tests that prove my fix is effective or that my feature works.
• New and existing unit tests pass locally with my changes.
• I have manually tested my changes end-to-end.
• Any dependent changes have been merged and published in downstream modules.

Additional context

Adds --reload_agents [boolean] option to both npx adk web and npx adk api_server, matching the --reload_agents flag in adk-python.

Implementation:

• AgentLoader accepts a new watchForChanges constructor parameter (default false).
• After the initial preloadAgents() call, if watchForChanges is true, a fs.watch watcher is started on the agents directory using the Node.js built-in fs module (no new dependencies).
• When a JS/TS file change is detected, invalidateAll() disposes all cached AgentFile instances and resets agentsAlreadyPreloaded = false, so the next request triggers a fresh scan.
• disposeAll() closes the watcher to prevent resource leaks on shutdown.
• AdkApiServer forwards the reloadAgents option from server config to AgentLoader.

[kalenkevich]

Thanks

[nuthalapativarun]

Hi @kalenkevich — I've addressed all the review comments (replaced console.log/console.warn with logger, added --reload_agents to the run command with onAgentFileReloaded callback, updated the description). Could you take another look when you get a chance? Thanks!

[nuthalapativarun]

Hi @kalenkevich — this PR is approved and mergeable. Could you merge when you get a chance? Thanks!

[nuthalapativarun]

Rebased on current main — the branch is now up to date and ready to merge. Thanks again for the approval @kalenkevich!

[nuthalapativarun]

Found and fixed the Windows CI failure. The issue was not in the hot-reload implementation itself, but in test files that were merged in from main (#372\ and #374) and contain bare \�s any\ casts that ESLint rejects.

Root cause: On Linux/macOS CI, bash passes */**.ts\ to ESLint as a literal string (bash *\ requires globstar). ESLint handles the glob internally and evaluates it from the repo root, but the files happen to be scanned in a different order or subset. On Windows CI with PowerShell, the shell expands **/**.ts\ itself, producing a different (larger) file list that includes the test files — exposing the 3 @typescript-eslint/no-explicit-any\ errors.

Fixes applied:

• \core/test/agents/processors/basic_llm_request_processor_test.ts: imported \Modality\ from @google/genai\ and replaced 'AUDIO' as any\ with \Modality.AUDIO\
• \core/test/code_executors/code_execution_utils_test.ts: imported \Content\ from @google/genai\ and replaced the two \�s any\ casts with \�s unknown as Content\

All tests still pass locally.

[nuthalapativarun]

Rebased onto current main to fix the cla/google check. The previous branch history included merge-from-main commits that dragged in third-party author commits (sukhmanghotraa, AmaadMartin), which caused the CLA bot to fail. The branch now contains only 3 commits — all authored by me. CI should go green shortly.

[nuthalapativarun]

Rebased onto current main (now at 04968b7) — the branch is up to date and CI should go green. Could you merge when you get a chance? Thanks @kalenkevich!