What happened
CoWork OS, an open-source agent workspace, released version 0.5.62 on GitHub. The GitHub release is dated October 31, 2026; its changelog entry is dated October 30. The release groups several additions around where an agent can execute, what interface it can use, and which credentials it can reach.
First, it adds opt-in “Task computers”: Linux execution associated with a task, with takeover and explicit file transfers. It also adds Web Access, which exposes the full application in a paired browser. The release describes approval-aware 3D generation through Meshy as part of this scope. Separately, CoWork can direct its computer-use tools to a Cua Space rather than the local computer. The tools listed are screenshot, click, type_text, keypress, scroll, and drag. That connection requires a Space URL and token; a test checks the endpoint and token. The token is encrypted, is not sent to the renderer, and is discarded when the Space address changes. If the Space cannot be reached, an action fails rather than falling back to the user's desktop.
The most detailed change is secret handling. API-key fields, as well as an MCP server's environment variable or header, can now contain a reference rather than the key itself: op://vault/item/field for 1Password, bws://<secret-id> for Bitwarden Secrets Manager, or bw://<item>/<field> for a Bitwarden item. CoWork reads the requested value through the vault's own command-line interface when the request needs it. It keeps the value in memory for up to ten minutes and stores only the reference in settings.
The setup lives under Settings > System & Security > Password Managers. The release calls for a 1Password service-account token, a Bitwarden Secrets Manager access token, or a Bitwarden unlock with a master password, and provides a reference test. An unreadable reference stops the request and reports what must be fixed; it does not silently use an older value. Values obtained this way are masked in command output, MCP tool results, and memory. MCP servers also no longer inherit vault tokens from CoWork's environment. The cowork run command supports the same references, while cowork providers list identifies keys that come from a vault.
Version 0.5.62 also makes --provider and --model actually pin a single cowork run task to a chosen model without changing the global default. Previously, the release says, the command accepted both flags but ignored them. An unknown or unconfigured provider now stops the run before task creation; the resolved model is printed, including as task_model in JSON output. Remote runs require --model. Finally, the bot detail panel gains a “What it can do” card, built from the same checks that enforce its limits, covering working locations, autonomous file use, services, schedules, memory, and actions requiring approval.
What the archive adds
This is a new event on CoWork OS, but it intersects two recent threads. 1Password for Agents described password-manager-mediated agent sign-in with user approval. Cua Spaces covered remotely backed computer-use spaces and sign-in work. CoWork now combines comparable concerns inside one workspace: task execution can be remote, while secrets are referenced instead of copied into configuration.
Trend signal
This supports agent security moves to runtime boundaries. CoWork's release describes several enforceable boundaries rather than prompt-level assurances: a vault reference instead of a stored key, masked outputs, no inheritance of vault tokens by MCP servers, encrypted Space credentials, and failure rather than local-desktop fallback. The release does not establish that these controls are sufficient, but it is a concrete implementation of the pattern.
Why it matters
Teams often give agents browser, shell, MCP, and API access in the same workflow, which makes secret propagation a practical design problem. This release presents an alternative to placing API values directly in settings or passing broadly inherited environment variables. A task can request a reference; the workspace resolves the value on demand, masks it in several output surfaces, and refuses to proceed when resolution fails.
The execution changes matter for the same reason. Sending computer-use actions to a configured remote Space and failing if that Space is unavailable is a clearer operational boundary than quietly reverting to a local desktop. Per-run model pinning also lets teams compare or route tasks without changing a workspace-wide default. None of these features eliminates the need to review MCP permissions, vault policy, or agent actions, but they make those controls more observable and specific.
What happens next
- Agent workspaces will expose more per-task execution and credential boundaries. (6 months, 65%). Watch for: explicit task-scoped identities, vault policies, and execution-target audit records.
- MCP integrations will increasingly avoid inheriting broad host credentials. (12 months, 60%). Watch for: scoped secret injection and tool-specific authorization controls.
Limits and uncertainty
The release notes are a product description, not an independent security assessment. They do not establish how the vault CLI, service-account tokens, or Bitwarden unlock state are protected outside CoWork, nor do they describe a full audit trail for secret access. “Masked” output does not by itself prove that a secret cannot reach every logging, network, or downstream tool path. The notes also do not quantify performance, reliability, adoption, or the practical isolation properties of Task computers and Cua Spaces. Teams should test the behavior against their own MCP servers, operating systems, vault configuration, and rollback procedures; the release specifically warns that returning to 0.5.61 or earlier after secret re-encryption cannot read the newer secrets.
Skill to build now
Map one agent workflow into four concrete scopes: execution target, files, external tools, and credentials. Replace a directly stored test API key with a password-manager reference where the surrounding tooling supports it, then verify three outcomes: the request succeeds, the value is not shown in command or tool output, and a broken reference stops the task rather than selecting a stale fallback. Repeat the exercise for one MCP server and inspect whether it inherits any unnecessary environment variables.
Reader takeaway
CoWork OS 0.5.62 is a small workspace release with a useful architectural lesson: agent capability should be attached to explicit, testable runtime boundaries. Remote execution, per-task model choice, and vault-backed secret references are more actionable controls than a broad promise that an agent will handle credentials carefully.
Open question
Can CoWork provide operators with an inspectable record of which task resolved which secret reference, for which tool call, without exposing the secret itself?