[Bug] first-tree-read can emit contextDecision receipt in Chat body instead of metadata

[yuezengwu]

Summary

A Codex agent using the shipped first-tree-read 0.3.0 contract emitted the full contextDecision receipt as visible Chat markdown and omitted metadata.contextDecision. The Web did not expand hidden metadata; the agent constructed a malformed final chat send.

This pollutes the user-facing reply and means downstream receipt consumers cannot find the receipt even though a JSON block appears in the message body.

Surface Area

• agent runtime (codex)
• Chat CLI/message transport
• Context Tree first-tree-read receipt flow
• Web Chat (visible symptom only; current Web code has no contextDecision renderer)

Environment

• First Tree staging CLI: 0.5.17-staging.939.1 (captured after the incident)
• first-tree-read: 0.3.0
• install method: managed First Tree staging client/workspace
• runtime: codex
• operating system: macOS 26.5.2, Darwin 25.5.0 arm64

Reproduction

1. In a long-lived QA Chat, run several Codex turns/compactions while reading decision-bearing Context Tree nodes and preparing a final QA report.
2. Have the agent send the final report through first-tree-staging chat send ... -F final-message.md.
3. Inspect the persisted message with first-tree-staging chat history <chat-id>.
4. Observe that the receipt JSON is in content, while metadata.contextDecision is absent.

The sanitized runtime trace for the observed occurrence shows:

apply_patch -> final-message.md contains:
  Context Tree receipt：
  { "contextDecision": { ... } }

first-tree-staging chat send gandy2025 -f markdown -F .../final-message.md
# --metadata was omitted

Expected Behavior

When Tree context materially affects the final choice, the same final chat send or blocking chat ask should:

• keep receipt JSON out of the visible message body; and
• attach one top-level metadata.contextDecision object.

The receipt must never be a separate receipt message or a prose-only claim.

Actual Behavior

Persisted message 019f923f-8202-7890-82dd-5f6ffb26b021 contains a visible Context Tree receipt: JSON block. Its metadata contains only the recipient mention and has no contextDecision.

An earlier message in the same Chat correctly used -m/--metadata, proving the CLI/Server metadata path itself works. This occurrence is an agent-side protocol/enforcement failure.

First Tree Context

• Reporting Chat ID: 96f2acfa-b02c-478b-9280-3da456ebfe03
• Affected Chat ID: 99892338-338e-48f5-a91a-984518368cee
• Affected Message ID: 019f923f-8202-7890-82dd-5f6ffb26b021
• Reported by (user): gandy2025
• Agent: yzw-codex

Additional Context

• The current first-tree-read floor test statically checks that SKILL.md says receipt metadata is same-message and not prose.
• Existing gate cases primarily validate skill triggering and returned Tree facts; they do not assert the persisted final message transport shape.
• The QA report's 30/30 and 32/32 results covered first-tree-seed, first-tree-welcome, and generated briefing tests, not receipt transport.
• Suggested first regression: a real message-level case asserting that content excludes receipt JSON and the same message includes metadata.contextDecision. A transport-level guard can be considered after that focused case.
• Duplicate searches for contextDecision receipt metadata body, "Context Tree receipt" chat body, and first-tree-read receipt prose returned no matching issue.