## Why
The OpenAI-compatible API endpoints (`openai-http.ts`, `openresponses-http.ts`)
were returning raw `String(err)` in error responses. This can leak sensitive
internal information to HTTP clients:
- Stack traces revealing code structure
- File paths exposing server directory layout
- Internal error messages from dependencies
This is the same class of vulnerability that was fixed in #2387 for
`server-http.ts`, but these OpenAI-compatible endpoints were missed.
## What
Replace `String(err)` with safe error messages:
- **500 errors (api_error)**: Return generic "Internal server error"
- **400 errors (invalid_request_error)**: Return `err.message` only
(no stack trace), with fallback to "Invalid request"
## Changes
- `src/gateway/openai-http.ts`: 2 catch blocks sanitized
- `src/gateway/openresponses-http.ts`: 4 catch blocks sanitized
- Add input_image and input_file support with SSRF protection
- Add client-side tools (Hosted Tools) support
- Add turn-based tool flow with function_call_output handling
- Export buildAgentPrompt for testing
Add a new `/v1/responses` endpoint implementing the OpenResponses API
standard for agentic workflows. This provides:
- Item-based input (messages, function_call_output, reasoning)
- Semantic streaming events (response.created, response.output_text.delta,
response.completed, etc.)
- Full SSE event support with both event: and data: lines
- Configuration via gateway.http.endpoints.responses.enabled
The endpoint is disabled by default and can be enabled independently
from the existing Chat Completions endpoint.
Phase 1 implementation supports:
- String or ItemParam[] input
- system/developer/user/assistant message roles
- function_call_output items
- instructions parameter
- Agent routing via headers or model parameter
- Session key management
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
