Hi ICP team & community 
,
Huge congrats on the recent releases — the runtime canister ID injection via ic_env cookie served by the asset canister in production is excellent DX. Browser code automatically discovers PUBLIC_CANISTER_ID:<name>=<id> mappings without any hard-coding.
The local pain point In production: seamless — asset canister sets the ic_env cookie on HTML responses → agents/libs read it at runtime. Locally (e.g., vite dev + local replica with icp-cli), there’s still no built-in, zero-friction equivalent. Devs typically resort to:
- Manually parsing .icp/cache/mappings/local.ids.json (generated by icp-cli after deploy)
- Injecting via process.env (if using build-time env output)
- Custom scripts, Vite plugins, or dev-server middleware
This creates extra steps during fast local iteration, especially in React/Vite/TanStack Query setups (common in the ecosystem).
Approaches we’ve explored / would love feedback on
- A simple CLI helper (e.g. icp env set-local or icp dev env) that reads/updates local mappings after icp deploy and optionally injects a mock ic_env cookie or header for the dev server.
- SDK/JS-agent utility like safeGetCanisterEnv() (experimental in js-sdk?) with clear fallbacks: cookie → env var → .icp/cache/mappings/local.ids.json → import.meta.
- Lightweight Vite plugin/middleware to auto-set the cookie/header when local mappings are detected.
Two quick questions for the team/community:
- Is relying on the ic_env cookie (or similar runtime injection) the recommended pattern for local dev as well — even if it needs a little glue code today?
- Are there plans (or active work) for first-class icp-cli/SDK helpers to auto-populate/serve these mappings locally after deploy (e.g., cookie injection or env helper)?
This is a minimal template that I’m working on using icp-cli + ic-reactor!
Thanks for the great platform — loving the direction toward less hard-coding and better build/deploy separation! 