Interactive -i startup prompt is ignored with custom/BYOK provider in TTY sessions

[shukebeta]

Summary

When Copilot CLI is started in interactive TTY mode with a custom/BYOK provider, the startup prompt passed via -i/--interactive is not auto-submitted.

The same -i flow works with the standard provider in the same tmux session.

Version / environment

• Copilot CLI: 1.0.75
• OS: Linux
• Reproduced in: tmux pane / interactive TTY
• Provider type: custom anthropic-compatible provider via COPILOT_PROVIDER_*

Reproduction

Control case: standard provider works

Run this inside a tmux pane / interactive TTY:

copilot --yolo -i "hi"

Observed:

• TUI opens
• hi is auto-submitted as the first user message
• The session responds normally

Failing case: custom/BYOK provider drops the startup prompt

Run this in the same kind of tmux pane / interactive TTY:

COPILOT_PROVIDER_BASE_URL=https://example.invalid \
COPILOT_PROVIDER_TYPE=anthropic \
COPILOT_PROVIDER_API_KEY=redacted \
COPILOT_MODEL=Minimax-m3 \
copilot --yolo -i "hi"

Observed:

• TUI opens successfully
• No hi bubble appears
• The session is idle at the normal / commands · ? help ... prompt
• Nothing is sent to the model

Expected:

• hi should be auto-submitted exactly like the standard provider case

Important contrast

If I manually type hi and press Enter after the TUI opens in the BYOK/custom-provider case, the request is sent successfully.

So this does not appear to be a basic auth/network/startup failure. It looks specifically like the startup prompt from -i is being dropped on the custom/BYOK provider path.

Additional notes

• I reproduced the same behavior whether the model is provided via COPILOT_MODEL=... or --model ...
• In the failing case, the log shows startup reaching cli_ready, but there is no corresponding user_message, assistant.turn_start, or model.call_start
• In the working standard-provider case, the log does show the initial hi being submitted

This feels like an interactive startup regression specific to the custom/BYOK provider path.

[shukebeta]

Additional clue from logs after more local reproduction:

In the failing custom/BYOK-provider case, one notable log line is:

No model backend (auth, legacy provider, or BYOK registry) available, skipping custom agents load

This makes it look possible that the interactive startup prompt from -i/--interactive is being processed before the custom provider / BYOK backend is fully ready, so initialPrompt gets dropped.

That would also fit the observed behavior that:

• the TUI starts successfully,
• the startup -i "hi" prompt is never submitted,
• but if I manually type hi after the TUI is already open, the request is sent normally.

So one plausible hypothesis is a startup ordering / readiness race on the custom-provider path, rather than a generic parsing or shell issue.

[shukebeta]

One more useful data point: this appears to be a regression window, not a longstanding limitation of BYOK/custom providers.

I tested older versions side-by-side in the same tmux / interactive TTY setup:

• 1.0.16 + standard provider: -i "hi" auto-submits ✅
• 1.0.16 + BYOK/custom provider: -i "hi" also auto-submits ✅
• 1.0.68 + BYOK/custom provider: -i "hi" is not submitted ❌
• 1.0.75 + BYOK/custom provider: -i "hi" is not submitted ❌

So this looks like a regression introduced sometime after 1.0.16 and by 1.0.68.

That may help narrow the search quite a bit, especially around interactive startup / initial prompt handling on the custom-provider path.