You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Preserve provenance for extension custom messages at the LLM boundary #228
Extension-injected custom messages preserve customType and distinct TUI rendering in session state, but convertToLlm() unconditionally converts every role: "custom" message to role: "user" and drops its provenance metadata.
This is especially risky for asynchronous extensions: subagent output and background-process stdout may contain untrusted repository/web/process text, yet the parent model receives it at the same role tier as literal human instructions.
The issue is not that the TUI confuses the messages; it does not. The trust/provenance loss happens at the model boundary.
Desired design
Introduce a durable internal observation/provenance contract for extension-generated context. Provider adapters may still need to serialize observations into available provider roles, but the transformation should preserve source/type metadata and apply a standard non-spoofable framing/policy rather than silently treating observations as human-authored input.
Acceptance criteria
Extension-generated observations are distinguishable from literal user messages through the full session-to-provider pipeline.
Provenance includes at least extension/custom type and an explicit trust classification.
Provider conversion has a documented strategy for APIs without a native observation/tool role.
Async child/process output is framed as untrusted data and cannot override higher-priority instructions by role implication.
Existing custom messages remain session-compatible or migrate safely.
Activity