Regression introduced by merged PR #23068 -- bug fix

[FlorianOtel]

Description

What ddc30cd15 was supposed to fix

• Commit: ddc30cd15 ? feat(core): add session metadata support (#23068)
• Date: 2026-05-30 21:58 UTC
• PR purpose: Add explicit agent and model fields (alongside a new metadata field) to the Session.create() / createNext() input shape. Prior to this refactor, those values lived implicitly inside the session creation flow; the PR's goal was to make them first-class, explicitly-passed inputs so that callers control them directly rather than relying on context-derived defaults.
• Affected surfaces:
  • packages/opencode/src/session/session.ts ? create() (~lines 740-785) and createNext() (~lines 580ff) now accept agent?: string and model?: Schema.Schema.Type<typeof Model> in their input shape.
  • packages/core/src/session/projector.ts ? sessionRow() (~lines 38-70) extracts these fields directly from the Info object when writing the DB row.

Regression it introduced

• Caller never updated. packages/opencode/src/tool/task.ts lines ~147-162 ? the only call site that creates a child session for a dispatched subagent ? still calls sessions.create() with only parentID, title, and permission. It never passes agent or model, even though the refactor made these explicit input fields.
• The model value is already computed at the same call site but never used at create. Lines ~170-198 of the same file derive const model = next.model ?? { modelID: msg.info.modelID, providerID: msg.info.providerID } and use it for the prompt invocation and metadata publish ? but never thread it back to the sessions.create() call eighteen lines above.
• Historic projector-based back-fill is no longer dependable. Before ddc30cd15, the DB columns were populated by projector handlers reacting to SessionEvent.AgentSwitched and SessionEvent.ModelSwitched events that session/prompt.ts emits on first prompt (the current?.agent !== info.agent comparison fires the event because current is undefined for a fresh session). After the refactor, this path no longer reliably populates the columns on Task-tool-spawned children ? likely because the emitted event payloads or comparison surfaces shifted, but the practical observable effect is unambiguous: child session rows have agent IS NULL, model IS NULL.

Net effect

• Every child session created via the Task tool from ddc30cd15 onwards has agent IS NULL and model IS NULL in the SQLite session table.
• Downstream consumers (any tool that reads ~/.local/share/opencode/opencode.db for subagent attribution ? telemetry, status-line, ad-hoc SQL, future tooling) cannot determine which subagent ran or which model handled a child session.
• The breakage is in upstream OpenCode dev HEAD AND in release v1.15.13 and later (since ddc30cd15 was tagged into v1.15.13 on 2026-05-30 23:40 UTC, ~1h42m after the bug landed).
• v1.15.12 and earlier are unaffected.

Plugins

None

OpenCode version

The reproduction only requires an OpenCode daemon built from dev HEAD (or any release v1.15.13+).

Steps to reproduce

Prerequisites

1. A built opencode binary from dev HEAD (or any release v1.15.13+). Verify version contains 0.0.0-{branch}-{timestamp} (local build) or 1.15.13+ (release).
2. An OpenCode server running on a known port (default 4096).
3. At least one agent definition installed at ~/.config/opencode/agents/<some-agent>.md with at minimum:

   ---
   name: minimal-test-agent
   description: Synthetic agent for reproducing the agent/model regression.
   model: anthropic/claude-haiku-4-5
   tools:
     Read: true
   ---
   You are a synthetic test agent. Respond with the literal string "ok" and nothing else.

4. sqlite3 CLI available.

Steps

# 1. Pick a synthetic working directory (not a real project ? avoids cross-test pollution)
TMPDIR=$(mktemp -d /tmp/oc-regression-XXXXXX)
cd "$TMPDIR"

# 2. Create a top-level (parent) session via SDK or REST against the running daemon.
#    Capture the returned session ID as PARENT_SID.
PARENT_SID=$(curl -sS -X POST \
  -H "x-opencode-directory: $TMPDIR" \
  -H "Content-Type: application/json" \
  -d '{"title":"regression-repro-parent"}' \
  "http://localhost:4096/session" | jq -r '.id')
echo "PARENT_SID=$PARENT_SID"

# 3. Send a user message that triggers a Task tool call dispatching the test agent.
#    The exact request shape depends on the SDK version; the goal is one assistant
#    turn that calls Task with subagent_type: "minimal-test-agent".
#    Pseudocode:
#
#    POST /session/{PARENT_SID}/message
#    {
#      "messageID": "msg_<descending_ulid>",
#      "model": { "modelID": "claude-haiku-4-5", "providerID": "anthropic" },
#      "agent": "general",
#      "parts": [{ "type": "text", "text": "Dispatch the minimal-test-agent via the Task tool with prompt: ok" }]
#    }
#
#    The assistant turn that follows will invoke Task, which creates a child session.

# 4. Wait for session-idle (the child session is now created and the agent has responded).

# 5. Query the SQLite session table for the child session row.
sqlite3 ~/.local/share/opencode/opencode.db <<SQL
SELECT id, agent, model, parent_id
FROM session
WHERE parent_id = '$PARENT_SID';
SQL

Observed (broken) output

ses_<child_id>|||ses_<parent_id>

(agent and model columns empty / NULL.)

Expected (post-fix) output

ses_<child_id>|minimal-test-agent|{"id":"claude-haiku-4-5","providerID":"anthropic","variant":"default"}|ses_<parent_id>

(agent populated with the dispatched subagent's name; model populated with the resolved model JSON.)

Pure-unit reproduction (no daemon, no DB)

A faster reproduction that doesn't need a running daemon is to call Session.create() directly with no agent/model (the same way task.ts does today) and assert via the projector that the row written to the DB has NULL agent and model. See §4 step 2 for the test shape ? this is the failing test that will be written first.

---

Screenshot and/or share link

None needed

Operating System

Linux Debian testing

Terminal

xterm

[FlorianOtel]

The PR that fixes this bug is #30741

[rekram1-node]

AUTOMATED REPRODUCTION BOT: I traced this against current dev and the relevant git history. This does not appear to be an accurate regression report as written.

ddc30cd15 added session metadata support. It did not introduce the explicit agent / model inputs to Session.create(), and it did not change the Task-tool child creation path, first-prompt switching logic, or the projector handlers. Those agent / model inputs were added earlier in a3bc5d35b.

There is a real but narrower gap: packages/opencode/src/tool/task.ts creates a fresh child session without eagerly passing agent or model, so the newly inserted row is initially NULL for both columns. However, the normal dispatched-child flow then invokes the real child prompt with agent: next.name and the selected model. SessionPrompt.createUserMessage() detects the blank row and publishes AgentSwitched and ModelSwitched; the durable event projectors synchronously update SessionTable.agent and SessionTable.model before prompt execution continues. A normally started or completed child prompt should therefore not remain NULL.

The lifecycle is:

Moment	Child agent / model
Immediately after child row creation	temporarily NULL
Once the child prompt starts	populated synchronously
After a normally completed child prompt	populated

The temporary gap is still worth hardening: an observer can briefly see unattributed rows, and a row may remain unattributed if execution fails or is cancelled before prompt admission. PR #30741 appears useful as an eager-attribution hardening change, but the evidence does not support attributing this to ddc30cd15 or saying that normally completed Task-tool children systematically retain NULL attribution.

One additional test note: a Task-tool test using a stub promptOps.prompt() bypasses the real SessionPrompt.createUserMessage() backfill path, so it demonstrates the creation-time gap, not the claimed completed-child failure.

[rekram1-node]

Are u certain? I dont think ur claim is accurate...

[FlorianOtel]

Are u certain? I dont think ur claim is accurate...

While your reply is to the bot findings, I had to double-check against my own deployment environment. It turns out that the bot was right on both counts:

1. Blame is mine a3bc5d35b (Refactor v2 session events as schemas #24512) introduced the explicit agent/model inputs to Session.create(), not ddc30cd15. I conflated them when writing this up.

2. The "regression" framing was too broad. My empirical evidence was production-DB rows from an older local build (8249768-based, June 1), not current dev. I didn't re-validate against current upstream before opening the PR -- that's on me.

I rebuilt current upstream/dev HEAD (730ea6d2e, which has #30786) on a clean temp DB and ran a real end-to-end Task dispatch via a local deployment of deepseek-v4-flash. The child row came back:

  id: ses_16c1ecb36ffe763XLO2U2erRdy
  agent: explore
  model: {"id":"deepseek-v4-flash","providerID":"local","variant":"default"}

So:

• agent is populated at creation by fix(opencode): attribute task child agent on creation #30786 <-- verified
• model is populated by the ModelSwitched event backfill -- including variant: default which my explicit-at-creation approach was missing. The bot's analysis on that mechanism was correct.

#30786 covers the real bug. #30741 was broader than warranted -- I will close it.

Thanks for the careful read and prompt reaction, much appreciated.

All the best,

/Florian

[github-actions]

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.