fix(store): an @local run hands its agents none of the configured store's credentials

[earakely-scale]

An @local run (a bundle run from the CLI) wraps the configured object store in LocalRunObjectStore, whose shared_credentials_env delegated to the configured store. A deployment whose store shares its credentials with workloads therefore handed every agent and judge the run deployed the caller's own cloud session, for example a developer's laptop session under a store configured to share. The workaround so far was a config copy swapping in a store that shares nothing.

An @local run doesn't need those credentials: its objects reach sandboxes through grants, staging or bytes agent-env pushes itself. So LocalRunObjectStore now shares none. snapshot_env already handed env services nothing inside an @local run; agents were the gap.

Not hot path: LocalRunObjectStore exists only inside CLI @local runs. Services never route.

Test: test_an_agent_deployed_in_an_at_local_run_gets_none_of_the_configured_stores_credentials covers both cases. An agent's container environment carries a sharing store's credentials when that store is configured directly, and carries none once the same store is wrapped for an @local run. The unit tier passes (6074).

🤖 Generated with Claude Code

Confidence Score: 5/5

The PR appears safe to merge.

What we checked:

• Local agents getting store credentials: Bundle tasks keep their deployment steps inside a local run scope. In that scope, the agent reads credentials from the wrapper, which returns none.

Summary

@local runs no longer pass configured object-store credentials into agent container environments, because their objects reach sandboxes through other paths.

• Agents in an @local run no longer get configured store credentials.

_{Reviews (1) · Last reviewed commit: "fix(store): an @local run hands its agen..." · Reviewed by Greptile}