VS Code doesn't realize that process has paused

[abacon]

lldb library version (local): 18.1.8
lldb-server version (remote): 18.1.8

I'm remote debugging a rust app that I'm cross-compiling from my M1 mac to an armv7-a device. I have lldb-server working on the remote device, and when debugging from command line on my mac everything works ok. I've got source maps, I can step through code, it's all working. Connecting via codelldb has been a little more complicated — this is what my launch.json looks like:

   {
      "name": "build and remote launch (debug)",
      "type": "lldb",
      "request": "launch",
      "initCommands": [
        "platform select remote-linux",
        "platform connect connect://10.0.1.51:1234",
        "settings set target.inherit-env false",
        "platform settings -w /mnt/onboard/.adds/leah"
     ],
     "cargo": {
        "args": [
          "build",
          "--bin=egui_template",
          "--target=arm-unknown-linux-musleabihf",
        ],
        "filter": {
          "name": "egui_template",
          "kind": "bin"
        }
      },
}

I've got a few breakpoints set, and the debug console shows that lldb is picking them up... and is stopped on one.

> breakpoint list
Current breakpoints:
1: file = '/Users/abacon/code/egui-fbink/example/src/main.rs', line = 16, exact_match = 0, locations = 1, resolved = 1, hit count = 1

  1.1: where = egui_template`egui_template::main::h8c79693e468dab93 + 16 at main.rs:16:5, address = 0x00018a9c, resolved, hit count = 1 

> process status
Process 1960 stopped
* thread #1, name = 'egui_template', stop reason = breakpoint 1.1
    frame #0: 0x00018a9c egui_template`egui_template::main::h8c79693e468dab93 at main.rs:16:5
   13  	use crate::app::TemplateApp;
   14  	
   15  	fn main() {
-> 16  	    env_logger::init_from_env(
    	    ^
   17  	        env_logger::Env::default().filter_or(env_logger::DEFAULT_FILTER_ENV, "debug"),
   18  	    );
   19  	    debug!("Starting the app");

But this is what vscode actually looks like:

It doesn't know that the process has stopped, and has no information about the current frame. If I muck about with pausing, stepping, etc, I can get it to a state where I get either Resume request failed - process still running. or Internal debugger error: Invalid thread id. depending on what I'm doing.

Does anyone have advice on where I've gone wrong? Thanks in advance!

[abacon]

Some additional info — I've mucked around with the codelldb logs and found the following lines, which appear illustrative:

[DEBUG codelldb::dap_codec] --> {"command":"threads","type":"request","seq":11}
[DEBUG codelldb::dap_codec] <-- {"seq":25,"type":"response","request_seq":11,"success":true,"command":"threads","body":{"threads":[{"id":1975,"name":"1: tid=1975"}]}}
[DEBUG codelldb::dap_codec] --> {"command":"stackTrace","arguments":{"threadId":1975,"startFrame":0,"levels":1},"type":"request","seq":12}
[ERROR codelldb::debug_session] Received invalid thread id in stack trace request.
[ERROR codelldb::debug_session] Internal debugger error: Invalid thread id.
[DEBUG codelldb::dap_codec] <-- {"seq":26,"type":"response","request_seq":12,"success":false,"command":"","message":"Internal debugger error: Invalid thread id.","show_user":true}

Running e.g. platform sh ps confirms that 1975 is the correct pid for the process. What's up??