Agent can't read @-referenced conversations (codeg://session/<id>) — reference passed as literal text, get_session_info not invoked

[noxenys]

Summary

When a conversation is @-referenced via [title](codeg://session/<id>), the
agent (observed with Claude Code) cannot read the referenced conversation's
content — even though the target session exists locally and is fully parseable.
Referencing an OpenCode session from a Claude Code session is the clearest repro.

Repro

1. In a Claude Code session, reference an OpenCode session:
   [打野](codeg://session/420) and ask it to look at that conversation.
2. The agent replies that it can't read the link, then tries to ls / read
   files and finds nothing (the target session's store is outside its sandbox).

Cross-check: referencing a Claude Code session (same-agent) from a Claude
Code session does work — the agent calls get_session_info and gets the
overview back. The failure is specific to the reference not being actionable,
not to any one agent's transcript store.

What I ruled out (with evidence)

• Not a missing companion. codeg-mcp is injected and running with
  --features delegation,feedback,ask,sessions; get_session_info is in the
  tool list for the session. A same-agent reference resolved fine through it.
• Not an OpenCode parser miss. The referenced ses_... ids resolve in
  ~/.local/share/opencode/opencode.db (session/message/part tables) with full
  message history.
• Not the parse timeout. PARSE_TIMEOUT is 8s; parsing those sessions
  measured ~3–6ms locally (a few hundred rows, N+1 part loads included).

Also note get_folder_conversation_core's ConversationNotFound fallback only
covers OpenClaw | Cline | Gemini — OpenCode isn't in it — but that path isn't
reached here since the id resolves directly, so it's not the cause either.

Actual cause

Two things stack up:

1. The reference is passed to the model as literal text only. A
   [title](codeg://session/<id>) mention arrives as the link text — the
   referenced session's content is never prefetched/injected into context.
2. In the failing transcripts the model doesn't call get_session_info on
   its own — it goes straight to Bash/file reads, and those can't reach the
   target store (a different workspace, outside the agent's fs sandbox).

So the tool that could resolve the reference exists, but nothing drives the
model to it, and the manual fallback is sandboxed out. This is a
reference-resolution / prompting design gap, not a data or parser bug.

Suggested directions

Either (or both):

• Prefetch + inject the referenced session's content (or a bounded summary)
  into context at prompt-assembly time when a codeg://session/<id> mention is
  present, so the model doesn't depend on calling a tool.
• Prompt-guide the model: when the message contains a codeg://session/<id>
  reference, instruct it to resolve it via get_session_info(<id>) before
  answering.

The first is more robust (doesn't rely on the model choosing to call the tool);
the second is lighter. Happy to send a PR for whichever direction you prefer.

Env

• codeg 0.21.9, Windows 11
• Referenced sessions were OpenCode; referencing session was Claude Code