[bug] text chat --messages-file - treats stdin as <drive>:\dev\stdin on Windows

[kissmemory]

Environment

• CLI: bl 1.8.1
• Installed skill/reference: 1.8.1
• Node.js: v24.15.0
• PowerShell: 7.6.1
• OS: Windows 10 Pro 22H2, build 19045.6466, x64
• Bailian site/region: domestic / cn-beijing
• Authentication: healthy; credentials redacted
• Invocation: terminal/agent on Windows

Reproduce

Run in PowerShell 7:

$messages = '[{"role":"user","content":"ping"}]'
$messages | bl text chat --messages-file - --output json --verbose

The installed text chat reference documents --messages-file - as the stdin form.

Expected

bl text chat should read the JSON message array from standard input, parse it, send the chat request, and return a completion.

Actual

The CLI exits before making the API request and treats the stdin sentinel as a filesystem path on the current Windows drive:

{
  "error": {
    "code": 1,
    "message": "File system error: ENOENT: no such file or directory, open 'F:\\dev\\stdin'",
    "hint": "File or directory not found.",
    "cause": {
      "message": "ENOENT: no such file or directory, open 'F:\\dev\\stdin'",
      "code": "ENOENT"
    }
  }
}

No request ID is available because the failure occurs locally before an API request is sent.

Control Check

The same installation, authentication, model path, and network work when the message is supplied directly:

bl text chat --message "ping" --output json --max-tokens 10

Result: exit code 0 with a normal qwen3.7-max chat completion.

Frequency

• Reproduced: 2/2
• The first reproduction used a real multi-message review payload.
• The second reproduction used the minimal ping JSON above with --verbose --output json.

Already Tried

• Confirmed CLI and installed skill/reference versions are aligned at 1.8.1.
• Confirmed bl auth status is authenticated.
• Confirmed direct --message requests succeed.
• Retried with a minimal JSON array, --verbose, and --output json; the same local ENOENT occurs.
• npm latest-version lookup could not be completed on this machine because the local npm cache returned EPERM; no upgrade was performed.

Likely Area

The Windows code path appears to resolve the - stdin sentinel through a Unix-style /dev/stdin filesystem path. On Windows this becomes <current-drive>:\dev\stdin instead of reading process stdin.

Please keep - as an stdin sentinel on Windows and read from process.stdin, or provide an equivalent documented Windows stdin path.

Privacy / Redaction

• API keys, access tokens, account identifiers, workspace identifiers, and console identifiers are omitted.
• The reproduction payload is the non-sensitive literal ping.
• The local drive letter is retained because it demonstrates the path-resolution symptom; it can be generalized to <drive>:\dev\stdin in the final report.