Feature Description
Due to Cortex's architecture and implementation as a transparent sidecar, currently when an outbound pipeline plugin (e.g. token-exchange or session-budget #723) denies or fails a request, the HTTP error (403, 503) is returned to the agent's internal HTTP client and not to the original caller. On the rossoctl platform this surfaces as a potentially cryptic error message like "can't connect to MCP service" instead of the a structured error message showing the original error.
Proposed Solution
Up for discussion, and may depend on how 'transparent' a sidecar we want cortex to remain, such as for a solution like response injection. This could also be surfaced through events more clearly.
Want to contribute?
Additional Context
No response
Feature Description
Due to Cortex's architecture and implementation as a transparent sidecar, currently when an outbound pipeline plugin (e.g. token-exchange or session-budget #723) denies or fails a request, the HTTP error (403, 503) is returned to the agent's internal HTTP client and not to the original caller. On the rossoctl platform this surfaces as a potentially cryptic error message like "can't connect to MCP service" instead of the a structured error message showing the original error.
Proposed Solution
Up for discussion, and may depend on how 'transparent' a sidecar we want cortex to remain, such as for a solution like response injection. This could also be surfaced through events more clearly.
Want to contribute?
Additional Context
No response