OpenWork’s August 27 commit deletes the standalone den-worker-proxy application. It makes refreshed, signed Daytona previews the shared way Web sessions, remote sessions, automations and provider setup find a worker. That matters when the connection expires: a Cloud workspace cannot make an old URL its permanent home if the current preview is meant to be short-lived.
The first angle was too simple. OpenWork has not abolished proxying or handed every client a direct preview link. The change adds an API compatibility route: a desktop client can ask it to resolve current access while the Web path receives a fresh preview. The project is moving the decision about where a Cloud worker lives into one resolution step, instead of letting clients remember an expiring host.
A URL can be a capability and a cache problem
The public signed-preview evaluation shows the practical shape. It seeds an expired preview, refreshes it, probes the new preview’s health endpoint, and expects the runtime to return the new URL with an expiry. The legacy connection, by contrast, receives a stable API worker route with no preview hostname. When that stable route is used, the new compatibility proxy resolves the current preview before forwarding the request.
A durable client address and a short-lived runtime address can coexist only if there is a clear place to refresh, authenticate and test the latter. The evaluation also refuses a redirect served by the sandbox-controlled health endpoint. It is a focused signal: the resolver is meant to ask whether this is the live destination, not blindly follow an address it was handed.
The middleman moved; the question became inspectable
For an operator, the audit question is concrete: which client receives an expiring preview, which receives a stable route, and where does that route re-check the worker? OpenWork’s test covers the intended split, a refreshed-preview case and a redirect refusal. It does not show a release, a default setting, a particular Daytona deployment or a complete security proof. The next signal is release guidance that makes preview expiry, compatibility routing and failure behavior a supported contract rather than source-code inference.