Feature request: Support Colab Secrets (userdata) in CLI mode

[exusiaiwei]

Summary

google.colab.userdata.get() does not work in CLI mode — it throws TimeoutException for every key. This forces users to hardcode API keys or use awkward workarounds to pass secrets (HF_TOKEN, WANDB_API_KEY, etc.) to scripts run via colab run or colab exec.

Steps to reproduce

colab run --timeout 30 script.py

Where script.py contains:

from google.colab import userdata
token = userdata.get("HF_TOKEN")  # TimeoutException

The same code works fine in the Colab web UI, where Secrets are configured via the sidebar.

Expected behavior

Secrets configured in the Colab web UI should be accessible in CLI sessions, since they are tied to the user account, not the notebook.

Current workarounds

• Pipe os.environ via echo ... | colab exec before running the actual script (ugly, leaks keys in shell history)
• Upload a dotenv file then read it in the script (extra step per session)
• Hardcode keys in scripts (not acceptable for shared/published code)

Proposed solution

Either:

1. Make userdata.get() work transparently in CLI sessions (ideal)
2. Add a colab secret set KEY VALUE CLI command to inject secrets into a running session
3. Add --env KEY=VALUE flag to colab run / colab exec

Option 3 would be the most agent-friendly — AI agents driving Colab CLI could read secrets from local env and pass them explicitly.

Environment

• colab version: 0.5.9
• OS: WSL2 (Ubuntu 24.04)
• Auth: --auth oauth2
• Colab Pro+ subscription

[teeler]

Thanks for the report. This is a known issue - I'll tag this for later work. User secrets are a separate API that needs some extra development.

[mvanhorn]

Implemented in #65 - feat: Add --env KEY=VALUE flag to colab run and colab exec to inject environment.

[teeler]

@exusiaiwei What do you think about what @mvanhorn implemented in #65? --env ?

[exusiaiwei]

Thanks @mvanhorn for the implementation! I tested the --env flag from #65 locally and it works great:

colab run --env HF_TOKEN=hf_xxx --timeout 60 script.py

The token was successfully injected into the remote kernel and I was able to authenticate with the HuggingFace API — exactly what I needed.

The current implementation is already usable and I'm happy with it. One minor suggestion for a future improvement: it would be nice to also support an --env-file option (similar to docker run --env-file .env) so that users with multiple secrets don't have to type out each --env KEY=VALUE on every invocation. But that's purely a nice-to-have — the current --env flag already solves the core problem.

Thanks again for the quick turnaround on this! 🎉

[teeler]

@mvanhorn env-file seems like a fine idea to me, but I'll leave it to you to decide to add that now (totally fine to skip, @sethtroisi or I can add it later)

Thanks for checking it out @exusiaiwei and for the excellent feedback