rolled back the bad idea and implemented proper wait

src/ghidra/bridge.rs

@@ -396,6 +396,10 @@ pub fn start_bridge(
 
 /// Stop the bridge for a project.
 pub fn stop_bridge(project_path: &Path) -> Result<()> {
+    // Read PID before sending TCP shutdown so we can wait for the JVM to
+    // fully exit (release project lock) before returning.
+    let pid = read_pid_file(project_path).ok().flatten();
+
     // Try graceful shutdown via TCP using BridgeClient
     if let Ok(Some(port)) = read_port_file(project_path) {
         let client = BridgeClient::new(port);
@@ -405,7 +409,7 @@ pub fn stop_bridge(project_path: &Path) -> Result<()> {
     }
 
     // Wait for the process to exit gracefully, then force-kill if needed
-    if let Ok(Some(pid)) = read_pid_file(project_path) {
+    if let Some(pid) = pid {
         // Wait up to 3 seconds for graceful exit
         for _ in 0..30 {
             if !is_pid_alive(pid) {

src/ghidra/scripts/GhidraCliBridge.java

@@ -128,10 +128,12 @@ public class GhidraCliBridge extends GhidraScript {
             }
         }
 
-        // Cleanup
+        // Cleanup: close the server socket but leave port/pid files for the
+        // Rust CLI to clean up. Deleting them here creates a race: the JVM is
+        // still unwinding (closing the Ghidra project, releasing locks) but
+        // stop_bridge() can no longer find the PID to wait on, so it returns
+        // early while the project lock is still held.
         serverSocket.close();
-        portFile.delete();
-        pidFile.delete();
     }
 
     // --- Request Handling ---