New application architecture

[t3dotgg]

Replaces the Electron app with a Node.js CLI (t3) that launches a WebSocket server and opens a browser-based UI to simplify deployment and improve accessibility.

This PR implements the requested architectural overhaul, migrating from an Electron-based application with IPC to a Node.js runtime (apps/t3) that hosts a WebSocket API and serves a browser-based frontend (apps/renderer). The apps/desktop package has been refactored into apps/runtime to contain the core provider and process management logic, now consumed by the new Node.js server. The npx t3 command now builds the frontend, starts the local server, automatically opens the web interface, and initializes the current working directory as a project with a new session. Electron and its related dependencies have been entirely removed.

---

 

---

[cursor]

Cursor Agent can help with this pull request. Just @cursor in comments and I'll start working on changes in this branch.
_{Learn more about Cursor Agents}

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch cursor/new-application-architecture-f8d0

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[macroscopeapp]

Replace Electron desktop app with apps/t3 Node runtime that serves a browser UI and exposes a WebSocket NativeApi for app bootstrap and RPC

Introduce a Node-based runtime and CLI that starts a WebSocket API server and a static web server, opens the browser, and wires the renderer to a WS-backed NativeApi. Add app.bootstrap to contracts and handle BOOTSTRAP_FROM_SERVER in the renderer store. Document the new architecture and update dev/build scripts to use the t3 CLI.

📍Where to Start

Start with the runtime entrypoint in main and server wiring: apps/t3/src/cli.ts, then the WebSocket API implementation in apps/t3/src/runtimeApiServer.ts. Review the renderer WS client in apps/renderer/src/wsNativeApi.ts and the bootstrap handling in apps/renderer/src/store.ts and apps/renderer/src/App.tsx.

Changes since #9 opened

• Introduced async runCli function that orchestrates CLI startup sequence and implements graceful shutdown with error recovery [e2a8f16]
• Refactored main CLI entrypoint to delegate startup to runCli with explicit error handling and exit codes [e2a8f16]
• Changed the condition for sending SIGKILL to timed-out terminal commands in runTerminalCommand to only force-kill when the child process has not exited and has not been terminated by a signal, checking child.exitCode === null && child.signalCode === null instead of checking !child.killed [cef4be1]
• Added test coverage in the runtime API server test suite to verify that terminal commands which trap and ignore SIGTERM are force-killed after the timeout period [cef4be1]
• Added test case for shell.openInEditor request handling with file-manager editor [abe616b]
• Added test case for shell.openInEditor method in runtime API server [a9fbb00]

---

📊 Macroscope summarized eb38f3c. 28 files reviewed, 26 issues evaluated, 11 issues filtered, 1 comment posted. View details

[macroscopeapp]

🟢 Low

src/wsNativeApi.ts:175 If any listener in handleEvent throws, handleMessage rejects and becomes an unhandled promise rejection (since it's called with void). Consider wrapping the handleEvent call in a try-catch.

-    if (parsed.data.type === "event") {
-      this.handleEvent(parsed.data);
-    }
+    if (parsed.data.type === "event") {
+      try {
+        this.handleEvent(parsed.data);
+      } catch {
+        // Prevent listener errors from causing unhandled rejections
+      }
+    }

🚀 Want me to fix this? Reply ex: "fix it for me".

[macroscopeapp]

🟢 Low

scripts/smoke-test.mjs:30 If the process exits before once('exit') is attached, the promise never resolves. Consider checking processRef.exitCode !== null first and resolving immediately if already exited.

Suggested change

	function waitForProcessExit(processRef) {
	return new Promise((resolve) => {
	processRef.once("exit", (code) => resolve(code));
	});
	}
	function waitForProcessExit(processRef) {
	return new Promise((resolve) => {
	if (processRef.exitCode !== null) {
	resolve(processRef.exitCode);
	return;
	}
	processRef.once("exit", (code) => resolve(code));
	});
	}

🚀 Want me to fix this? Reply ex: "fix it for me".

[macroscopeapp]

🟡 Medium

src/App.tsx:32 BootstrapRouter only bootstraps once on mount. If the initial call fails and the runtime later becomes healthy, the app stays in an uninitialized state. Consider adding runtimeError to the effect dependencies and retrying bootstrap when the error clears, or consolidating retry logic with RuntimeHealthRouter.

🚀 Want me to fix this? Reply ex: "fix it for me".

[devin-ai-integration]

✅ Devin Review: No Issues Found

Devin Review analyzed this PR and found no bugs or issues to report.

[macroscopeapp]

🟡 Medium

src/App.tsx:89 If api.app.health() takes longer than 8 seconds, multiple calls can overlap and stale responses may overwrite newer state. Consider adding an AbortController or sequence ID to ignore results from previous ticks.

🚀 Want me to fix this? Reply ex: "fix it for me".

[macroscopeapp]

🟡 Medium

src/wsNativeApi.ts:76 The connect() call hangs indefinitely if the WebSocket stays in CONNECTING state (e.g., firewall silently dropping packets), since the timeout isn't set up until after connection succeeds. Consider wrapping connect() with its own timeout, or starting the request timeout before awaiting connection.

🚀 Want me to fix this? Reply ex: "fix it for me".

[macroscopeapp]

🟡 Medium

src/wsNativeApi.ts:296 Consider using || instead of ?? here. An empty ?ws= query param returns "", which isn't nullish, so the fallback is skipped and new WebSocket("") throws.

Suggested change

	}
	return params.get("ws") || "ws://127.0.0.1:4317";

🚀 Want me to fix this? Reply ex: "fix it for me".

[macroscopeapp]

🟡 Medium

src/wsNativeApi.ts:170 Messages may process out of order because handleMessage is async but called without await. If a slow Blob.text() decode is followed by a fast string decode, the second message finishes first. Consider adding a message queue to preserve ordering, or document if out-of-order delivery is acceptable.

🚀 Want me to fix this? Reply ex: "fix it for me".

[devin-ai-integration]

Devin Review found 1 new potential issue.

View 8 additional findings in Devin Review.

[devin-ai-integration]

🟡 BOOTSTRAP_FROM_SERVER preserves stale thread errors on successful re-bootstrap

When the runtime re-bootstraps successfully after a previous failure, stale error messages persist on existing threads instead of being cleared.

Root Cause

In the BOOTSTRAP_FROM_SERVER reducer case at apps/renderer/src/store.ts:377, the error field for an existing thread is set via:

error: bootstrap.bootstrapError ?? entry.error,

When a bootstrap succeeds, bootstrap.bootstrapError is undefined (the field is optional in AppBootstrapResult at packages/contracts/src/ipc.ts:29). The nullish coalescing operator ?? then falls through to entry.error, preserving the old error.

Contrast this with the new thread path at apps/renderer/src/store.ts:353:

error: bootstrap.bootstrapError ?? null,

Here, undefined ?? null correctly evaluates to null, clearing the error.

Impact: A user who encounters a bootstrap failure (e.g. Codex can't initialize) will continue to see the stale error banner on their thread even after the runtime reconnects successfully. The error is only cleared by creating a brand new thread. This is especially problematic because the RuntimeHealthRouter in App.tsx clears runtimeError on successful health checks, so the global "Offline" indicator disappears while the thread-level error persists — giving contradictory signals.

Suggested change

	}
	error: bootstrap.bootstrapError ?? null,

---

Was this helpful? React with 👍 or 👎 to provide feedback.

[macroscopeapp]

🟢 Low

scripts/smoke-test.mjs:41 The setTimeout at line 44 leaks if the process exits before the timeout fires. Consider clearing the timer when the race resolves.

-  const exited = await Promise.race([
-    waitForProcessExit(processRef).then(() => true),
-    new Promise((resolve) => {
-      setTimeout(() => resolve(false), timeoutMs);
-    }),
-  ]);
+  let timer;
+  const exited = await Promise.race([
+    waitForProcessExit(processRef).then(() => true),
+    new Promise((resolve) => {
+      timer = setTimeout(() => resolve(false), timeoutMs);
+    }),
+  ]);
+  clearTimeout(timer);

🚀 Want me to fix this? Reply ex: "fix it for me".

🤖 Prompt for AI

In file apps/t3/scripts/smoke-test.mjs around lines 41-46:

The `setTimeout` at line 44 leaks if the process exits before the timeout fires. Consider clearing the timer when the race resolves.

[macroscopeapp]

🟢 Low

scripts/smoke-test.mjs:52 The SIGKILL fallback on line 53 awaits waitForProcessExit without a timeout, unlike the SIGTERM path. Consider adding a timeout here too to prevent indefinite hangs if the process fails to terminate.

-  processRef.kill("SIGKILL");
-  await waitForProcessExit(processRef);
+  processRef.kill("SIGKILL");
+  await Promise.race([
+    waitForProcessExit(processRef),
+    new Promise((resolve) => setTimeout(resolve, timeoutMs)),
+  ]);

🚀 Want me to fix this? Reply ex: "fix it for me".

🤖 Prompt for AI

In file apps/t3/scripts/smoke-test.mjs around lines 52-53:

The `SIGKILL` fallback on line 53 awaits `waitForProcessExit` without a timeout, unlike the `SIGTERM` path. Consider adding a timeout here too to prevent indefinite hangs if the process fails to terminate.

[macroscopeapp]

🟢 Low

scripts/smoke-test.mjs:573 If dist/cli.js is missing, the temporary directory created by createFakeCodexAppServerBinary() leaks because the throw happens before the try block. Consider moving the existence check before creating the fake binary, or wrapping the check inside the try.

-  const fakeCodex = createFakeCodexAppServerBinary();
-  const distCli = path.join(appRoot, "dist", "cli.js");
-  if (!fs.existsSync(distCli)) {
-    throw new Error("Missing dist/cli.js. Run `bun run --cwd apps/t3 build` first.");
-  }
+  const distCli = path.join(appRoot, "dist", "cli.js");
+  if (!fs.existsSync(distCli)) {
+    throw new Error("Missing dist/cli.js. Run `bun run --cwd apps/t3 build` first.");
+  }
+  const fakeCodex = createFakeCodexAppServerBinary();

🚀 Want me to fix this? Reply ex: "fix it for me".

🤖 Prompt for AI

In file apps/t3/scripts/smoke-test.mjs around lines 573-577:

If `dist/cli.js` is missing, the temporary directory created by `createFakeCodexAppServerBinary()` leaks because the `throw` happens before the `try` block. Consider moving the existence check before creating the fake binary, or wrapping the check inside the `try`.