I'm curious whether anyone else finds it frustrating that a tool expected to run locally still requires signing in. Does the sandbox actually depend on cloud resources, or is the login mainly for account management, governance, or usage tracking?
3 Answers
The official explanation is that signing in enables access to associated cloud resources and gives the service an identity for governance and account-level controls. So while the sandbox itself may run locally, the overall feature isn’t necessarily completely independent of the cloud.
It looks like this is more than a simple local-only application. Some functionality is tied to Docker’s hosted infrastructure, which is why the product wants an authenticated account even when the main workload appears to run on your machine.
That’s the part I’d like clarified: exactly which features use hosted resources and whether there’s a purely local mode without an account.
A login requirement can also be used for product governance, usage limits, and future service management. That doesn’t necessarily mean the tool currently needs substantial cloud compute, and it’s reasonable to be skeptical when the explanation mixes technical requirements with broad account-management language.
Exactly. The documentation gives a general rationale, but it doesn’t make the local-versus-cloud dependency especially clear.
That explains what the login enables, but it doesn’t fully justify making authentication mandatory for people who only want to use the local portion. The governance argument feels a bit weak unless there are real cloud operations involved.