facebook/flow · error

Unsupported CLI socket command: {}

Error message

Unsupported CLI socket command: {}

What it means

The CLI socket layer converts each incoming server_prot request Command into a CliCommand. The match covers every command the CLI knows; a command with no CLI representation hits this panic, printing the wire name of the command. In practice this fires on protocol skew: the wire enum deserializes fine, but the running server binary predates the command.

Source

Thrown at rust_port/crates/flow_server_env/src/server_socket_rpc.rs:697

                input,
                target,
                verbose,
                location_is_strict,
                wait_for_recheck,
                omit_targ_defaults,
            } => Self::INSERT_TYPE {
                input: input.into(),
                target: target.into(),
                verbose: verbose.map(VerboseWire::from),
                location_is_strict,
                wait_for_recheck,
                omit_targ_defaults,
            },
            server_prot::request::Command::LLM_CONTEXT(input) => Self::LLM_CONTEXT(input.into()),
            server_prot::request::Command::STATUS { include_warnings } => {
                Self::STATUS { include_warnings }
            }
            command => panic!(
                "Unsupported CLI socket command: {}",
                server_prot::request::to_string(&command)
            ),
        }
    }
}

impl CliCommand {
    pub fn into_server_command(self) -> server_prot::request::Command {
        match self {
            CliCommand::APPLY_CODE_ACTION {
                input,
                action,
                wait_for_recheck,
            } => server_prot::request::Command::APPLY_CODE_ACTION {
                input: input.into_server_file_input(),
                action: action.into(),
                wait_for_recheck,

View on GitHub (pinned to f88ac94bcf)

Solutions

1. Stop the stale daemon so the next command spawns a server of the current version: flow stop (or kill the pid recorded in the server lock/log), then retry the command.
2. Verify client and server versions match: flow version against the version the daemon logs at startup.
3. Pin the editor plugin and CLI to the same release until daemons have been restarted.
4. If you maintain a fork, map unknown commands to an error response instead of a panic in this conversion.

Example fix

# before: old daemon still serving a new CLI's commands
flow lsp suggest ...  # panic: Unsupported CLI socket command: ...

# after: recycle the daemon so versions match
flow stop && flow lsp suggest ...

match send_command(cmd) {
    Ok(resp) => resp,
    Err(e) if is_unsupported_command(&e) => {
        flow_stop(&root)?;             // recycle the stale daemon
        wait_for_socket_release(&root)?;
        send_command(cmd)              // retry against a fresh, same-version server
    }
    Err(e) => Err(e),
}

When it happens

Trigger: A newer CLI or editor plugin sends a newly added command (e.g. LLM_CONTEXT-era additions) to a long-running older daemon on the socket: deserialization succeeds because the wire format is forward-compatible, then the TryInto<CliCommand> conversion panics on the unrecognized variant and kills the request handler.

Common situations: A daemon that survived a package upgrade still listening on the old socket; multiple Flow versions on PATH so client and server resolve to different releases; IDE plugin auto-updating ahead of the CLI; stale connections reused after a version bump.

Related errors

• Flow check failed!
• flow.js wasm export ${name} is unavailable
• Unknown exception reading from the server: {}
• Error sending command to server: {}
• Unable to determine executable path: {}

AI-assisted analysis of facebook/flow@f88ac94bcf (2026-08-20). Data as JSON: /api/errors/28a55a633cc91f9e. Report an issue: GitHub.