A CLI exits before the session gets going and the interface reports one line:
Provider turn failed.
Nothing in the thread, nothing in the server logs, no stack. The only trace is a warning that the query stream failed. This is pingdotgg/t3code#19571.
Why it happens
On macOS and Linux the supervisor spawns the CLI as a process-group leader, so plugin MCP servers the CLI starts get cleaned up when the session closes (PR #19322). The spawn uses stdio: ['pipe', 'pipe', 'ignore'].
The SDK's own spawn captures and redacts stderr before it lands anywhere. A wrapper that pipes stderr through itself loses that redaction, and unredacted CLI output can carry credentials, so the safe move is to send it to /dev/null. The cost is that the exit error keeps only the code or signal. The thing that would have explained the failure is discarded on purpose.
spawn(command, args, {
stdio: ['pipe', 'pipe', 'ignore'],
detached: true,
})
What to do
Run the configured binary or wrapper directly in a terminal. Its stderr is the diagnosis the supervisor threw away, and in the report the wrapper's refusal reason was sitting right there.
If you are the one writing the supervisor, do not just turn stderr back on. The redaction exists for a reason. Capture a redacted tail, or at least surface the exit code and signal as a first-class error so an early exit reads as "exited with code 2" instead of a bare failure. A redacted stderr tail is not shipped behaviour today, so the direct run is the workaround.