OpenCode Adds Session Metadata, and Suddenly Agent Runs Look More Like Workflows Than Chats

OpenCode v1.15.13 looks like a small release if you read it as a changelog. Read it as an operating signal and it says something more useful: coding-agent sessions are becoming workflow objects, not chat logs with better autocomplete.

The release, published May 30 at 23:40 UTC, adds custom session metadata through the API and SDK. It also changes config loading so settings are discovered from the opened location upward, fixes Anthropic Opus 4.7+ adaptive reasoning through the gateway so summarized thinking is preserved instead of replaced with empty blocks, and improves the terminal UI for inline tool errors. None of that is flashy. All of it lives in the layer that determines whether teams can run agents across real repos without losing context, policy, or debuggability.

This is where agentic coding is maturing. The early product question was “Can the agent edit code?” The operational question is now “Can the platform explain which session did what, under whose policy, with which budget, in which directory, through which client, and what happened when the tool failed?” That is less cinematic. It is also the difference between a useful runtime and a haunted terminal.

Metadata is the field where governance stops being vibes

The headline feature comes from PR #23068, credited to community contributor @shantur. The PR adds a JSON metadata column to OpenCode’s session table, threads metadata through session models and projectors, exposes it across create, get, update, list, and fork operations, regenerates the SDK surface, includes tests, and adds a database migration for existing installs. It also supports copy-on-fork behavior by default and treats metadata as optional when unset or cleared.

That implementation detail matters. Metadata is where the harness stores facts the model should not have to remember and the transcript should not have to imply: task ID, repository, owner, originating channel, policy profile, model route, budget, data-sensitivity tier, CI run, incident ticket, or experiment cohort. Without metadata, an agent run is mostly a blob: prompts, tool calls, responses, maybe a working directory if you are lucky. With metadata, it becomes an addressable unit of work that other systems can list, filter, fork, audit, resume, and bill.

Fork behavior is especially important for coding agents. Real agent work branches constantly. One session explores an implementation. Another reviews it. A third runs tests. A fourth tries a cheaper model or a different provider. If metadata does not copy or reset predictably across those branches, governance silently rots. A child run can lose the original risk label. A review session can keep an approval state it should not inherit. A cost center can disappear just as the expensive model starts doing the expensive thing. These are not hypothetical platform concerns; they are exactly the kind of boring bookkeeping failures that make enterprise agent deployments brittle.

The practical advice is simple: define your required metadata before session sprawl begins. At minimum, serious teams should require project ID, actor, surface, policy profile, model/provider route, budget, data-sensitivity tier, and trace destination for any session allowed to touch a real repository. Then decide which fields copy on fork. “Owner” may copy. “Review status” probably should not. “Risk tier” might copy until the child session changes the target files. The schema is not just storage; it is policy design.

Directory-aware config is a safety feature

The second important change is config loading from the opened location upward. That sounds like the kind of thing developers expect from every mature tool, because it is. But for agents, predictable config resolution is more than convenience.

Agentic coding happens in monorepos, nested packages, worktrees, generated sandboxes, remote sessions, and editor clients that may open a subdirectory instead of the repository root. Provider policies and directory-specific settings need to follow the actual work location. If they do not, the agent may route sensitive code through the wrong provider, miss a required bring-your-own-key configuration, ignore a project-level model restriction, or apply a permissive policy from a parent context where a stricter child policy should win.

This is the control-plane version of “wrong cwd.” Developers have all been burned by a command run in the wrong directory. Coding agents make that failure mode more expensive because the tool may continue confidently after the first mistake. Loading config upward from the opened location is boring because it is correct. Boring correctness is underrated in agent runtimes.

Teams using OpenCode should test this deliberately. Open nested projects, worktrees, and subdirectories. Verify which config wins. Confirm provider routes, permission modes, and local policies are the ones you intended. If a policy only works when the terminal is opened at the repository root by a careful human, it is not policy. It is a suggestion with a footgun attached.

Reasoning summaries and tool errors are part of the audit trail

The Opus 4.7+ adaptive-reasoning fix is also worth more attention than it will get. The release says gateway Anthropic Opus 4.7+ adaptive reasoning now keeps summarized thinking instead of returning empty thinking blocks. Teams should not store hidden chain-of-thought they are not meant to inspect. But supported reasoning summaries are part of how users and operators understand what happened during an agent run. Empty blocks create false opacity. They make a session harder to debug, harder to trust, and easier to misread after the fact.

This is one of the awkward interoperability problems of the multi-provider agent era. Models expose different reasoning modes. Gateways normalize them imperfectly. Clients render summaries in different places. Some traces should include explanations; some should include only outcome and tool-call evidence. The answer is not to pretend reasoning artifacts do not matter. The answer is to define exactly what is allowed to be captured, where it is shown, how long it is retained, and how it connects to tool decisions.

The terminal UI fix for inline tool rows and expandable failed-tool errors belongs in the same bucket. A failed tool call is not just a red line in the transcript. It is often the best clue about whether the agent misunderstood the environment, lacked permission, hit a flaky dependency, or tried the wrong operation entirely. Expandable error details turn failure from decorative noise into reviewable evidence. For coding agents, the difference between “tool failed” and “tool failed because this exact command exited with this exact error” is the difference between restarting the agent and fixing the harness.

ACP makes session shape matter more

The context from OpenCode v1.15.12 makes v1.15.13 more consequential. The prior release added ACP integrations that can send prompts, slash commands, and usage updates through acp-next, added OpenAI WebSocket transport behind OPENCODE_EXPERIMENTAL_WEBSOCKETS=true, handled ACP permission prompts correctly, used persisted session directories for existing-session requests, and surfaced subagent retry status.

Once ACP clients, WebSocket transports, gateways, SDKs, forks, and terminal sessions are all part of the same workflow, “session” cannot mean “the scrollback in this one TUI.” It has to mean a durable object with identity, policy, history, cost signals, permissions, and enough metadata for other surfaces to reason about it. Otherwise each client becomes a partial truth. The editor knows the prompt. The terminal knows the tool call. The gateway knows the model. The billing system knows the spend. Nobody knows the run.

That is why session metadata is not plumbing. It is the spine that lets the rest of the platform assemble a coherent story.

There is a developer-experience angle too. OpenCode’s repository had very large adoption during research — more than 167,000 stars and 20,000 forks in the collected metadata — which means small runtime semantics can affect a lot of workflows quickly. A metadata field copied incorrectly, a config file loaded from the wrong parent, or a reasoning summary dropped by a gateway will not stay a niche edge case for long. Agent tools with broad distribution need boring operational correctness because their users will find every weird environment combination available.

For teams building on top of OpenCode, the next step is not just upgrading. It is standardizing. Define the metadata schema. Make it part of session creation, not an optional afterthought. Test fork inheritance. Use metadata in audits and cost reports. Verify directory config resolution in real repo layouts. Capture failed tool details in traces. If using ACP, test permission prompts and usage updates from every client, because a policy that only works in one surface is not a policy.

The release is small. The direction is not. Coding agents are moving from “chat that can edit files” toward distributed workflow runtimes with policy, metadata, transports, forks, and audit trails. OpenCode v1.15.13 is one of those incremental releases that does not win a launch thread but does make the product more operable. That is the work now. The demo era made agents impressive. The metadata era decides whether they are manageable.

Sources: GitHub — OpenCode v1.15.13, PR #23068 — session metadata support, OpenCode v1.15.12, Agent Client Protocol project context.