v0.4.38

A secret can now be a file in one of your workspaces. Plenty of credentials already live as files inside a container — a ~/.netrc, a service-account JSON, a PEM key some tool wrote. Copying one into DevGrail made a second copy that went stale the moment the original was rotated. A secret can now point at a workspace and a path instead, and the file's contents are its value.

It is read fresh every time, not copied: rotate the file and the next script run picks up the new value, with nothing to update in DevGrail. Trailing newlines are trimmed, because almost every token file ends with one and almost no program wants it; nothing else about the file is touched, so a PEM key or a .env block keeps its shape. The workspace does not have to be running. The file is read once when you save, so a mistyped path is refused in the editor rather than surfacing days later as a failed run — and if the workspace is later deleted or the file moved, the run says which, by name.

Everything else about a secret is unchanged. It is still referenced as @ in a script, still injected server-side, still redacted from the run output, and still fills the same reference slots an official script names. Pick a file with the new Browse button on the secret editor, which walks the workspace's filesystem.

Agents can manage these too, and still cannot read one: create_secret and update_secret take a container and a path, list_secrets and get_secret report which file a secret points at, and no tool returns the contents — reading that file still takes read_file and a grant on the container it lives in. Naming a workspace as a secret's source requires the same read grant, so a key cannot use a secret to reach a container it was never given.

A second getting-started guide, for Codex. It builds the same thing the OpenCode guide does — a project, a workspace container, and an API key scoped to just those two — and then points Codex at DevGrail using the official "All agents: connect to DevGrail (MCP)" script, downloaded from the registry as part of the run. Codex still needs a sign-in of its own, which happens in a terminal rather than in DevGrail, so the guide says so, names the option that finishes from a container ("Sign in with Device Code", against a ChatGPT subscription you already have) and hands you a button that opens a full-screen terminal in a new tab with codex already starting in the new workspace. Both guides sit under "Get started with your favorite coding agent" on the Guides page, which now lists sections rather than individual guides. The original guide is called "Get started for free with OpenCode", and says outright that OpenCode is open source and can be pointed at models that cost nothing — so a first workspace need not cost you anything either.

Automations can install from the official registry. A new "Download an official script" step fetches a script by its slug, installs it into your library and publishes its id, so the next step can run it — which is how the Codex automation gets its setup script without the binary carrying a copy. A script you already have is wired to rather than copied again, and nothing you hold is quietly moved to a newer version unless the step asks for it.

The built-in "Get started with OpenCode" automation now issues a key the agent can actually build with. Alongside the new project and workspace it was always scoped to, the key reads every skill and script in your account — the ones you have now and the ones you add later — and the official registry, so the agent can install a ready-made skill or script instead of writing one from scratch. It can also list your secrets and API keys by name, which is how it references them from a script; a secret's value and a key's plaintext stay unreadable, and it can neither create, change nor delete either. Keys minted by earlier runs are untouched — re-run the automation, or widen the key on its own page.

Automations of your own can grant the same. A "Create an API key" step now has Scripts and Official registry fields beside Skills, so a key an automation mints can reach your script library and download from the official catalog. Both grant nothing unless you ask, so every automation you already have mints exactly the key it minted before.

An agent can now pass on its access to the official registry. The key-creation tools accepted every kind of grant except that one, so an agent holding the registry could browse and download from it but could not hand a helper key the same reach — and a key that held it could not be renamed, disabled or deleted over MCP by anyone. Both work now, under the rule the other grants already followed: an agent can only pass on what it holds, and read (browse) does not become write (download).

The get-started guide tells you when your workspace is ready. The automation runs on the server, so it used to finish in silence — four checkmarks filling themselves in while you were reading the step below. Now the end of a run is announced, the browser tab says so if you have looked away, and step 1 keeps a note naming the workspace it built and linking to it, so the page still tells you where things stand when you come back to it.

The guide's second step no longer points at a workspace that is not there. "Open OpenCode" now says what it is waiting for while step 1 has not run, and when the run finishes the page scrolls to that button rather than leaving you to notice it. Reopening the guide after deleting the workspace it built offers to build a new one instead of opening a container that is gone.