[bug] text chat --api responses --tool web_search: non-streaming requests systematically fail with headers timeout; --stream works #239

Environment

• CLI: bl 2.1.0
• Skill: 2.1.0
• Node: v25.9.0
• OS: macOS 26.5.2 (arm64)
• Region: cn-beijing (domestic; config profile token-plan, base_url https://token-plan.cn-beijing.maas.aliyuncs.com)

Reproduce

# Non-TTY (agent) invocation — systematically times out:
bl text chat --api responses --tool '{"type":"web_search"}' --timeout 300 \
  --system "Reply in 简体中文。" \
  --message "<a search question>"

# Same request with forced streaming — succeeds:
bl text chat --api responses --stream --tool '{"type":"web_search"}' --timeout 550 \
  --system "Reply in 简体中文。" \
  --message "<the same search question>"

Expected

Both invocations return the model's answer with web search results.

Actual

Without --stream: request systematically fails with headers timeout — Error: Network request failed: UND_ERR_HEADERS_TIMEOUT: Headers Timeout Error (exit 6) or Error: Request timed out ... This operation was aborted (exit 5). ~13 of 14 attempts failed over a period of hours; the single success took several minutes.

With --stream: 3/3 attempts succeeded, responses returned normally.

Analysis

bl text chat --help says --stream Stream response tokens (default: on in TTY). In non-TTY (agent/pipe) context the default is non-streaming, so the CLI waits for the full Responses-API + web_search run (multi-round searches, server-side) before receiving response headers — which reliably exceeds the gateway's headers timeout. Streaming receives headers early and works. Suggestion: for --api responses with tools (or in non-TTY generally), default to streaming, or automatically retry with streaming on UND_ERR_HEADERS_TIMEOUT.

Already tried

• bl update / skill version aligned (2.1.0 across CLI, npm, skills)
• Network ruled out: direct curl --noproxy '*' to the endpoint returns 404 in ~0.1s; same with system proxy — no local connectivity issue
• --timeout raised to 550s — non-streaming still fails; streaming succeeds with the same timeout
• Multiple retries over several hours: non-stream failure rate ~13/14, stream success 3/3

Notes

• Frequency: always (non-streaming); none so far (streaming)
• Invoked via: agent (non-TTY automation)
• No request ID available: headers timeout means no response headers/ID were ever received