fix(desktop): resolve WSL backend getting stuck connecting (#3611) - #3623

💭 I'm reviewing the diff to check if it follows Effect service conventions, looking at the TypeScript imports across the desktop and server apps. The imports are using namespace syntax like import * as Fiber from "effect/Fiber", which looks correct, but I'm noticing something odd with the PlatformError import—it's coming from effect/PlatformError when it should probably be from @effect/platform instead. This is a bug-fix PR rather than a service refactor, so the Effect service conventions might not even apply here. Let me check the actual source files to see if any of these changes involve creating, moving, or refactoring Effect services. I need to adjust the repo parameter to use the proper URL object format. I'm looking at the unmarshaling error more carefully—the repo parameter should be an object with a url property, but the parser is complaining about the structure. Let me trace through what I'm actually passing versus what RepoToolCallParams expects, since the error suggests there's a mismatch in how the nested fields are being handled. The repo parameter seems to be coming through as a string when it should be an object with a URL field. Let me try using git_grep instead, which uses the same repo format, or maybe I need to flatten the structure—though the schema clearly defines repo as an object. I'll retry to see if this was just a transient issue. Let me switch to using the git_grep tool to examine the file contents directly. I'm running into a marshaling issue where the repo parameter is being received as a string instead of the object the schema expects. The error suggests it might be double-encoded, so I'm wondering if I should pass just the URL string directly, though the schema definition clearly calls for an object structure. Let me try switching to the code_research_query tool instead, which accepts repo_urls as a list of strings—that might sidestep this serialization problem entirely.

1. github_api_read_only — Show the full current contents of apps/server/src/bootstrap.ts, focusing on the readBootstrapEnvelope function, including the cleanup() definition, the error listener registration on input vs stream, and where cleanup() is called on each terminal branch.

💭 I might need to reference the branch directly or use the head commit SHA instead of relying on refs. The view tool keeps hitting the same unmarshal error no matter what I pass, which suggests this is a deeper issue with how the harness is handling the object parsing. Let me try a different approach with git_grep using the commit SHA, though I'm getting the same unmarshaling error there too. I'll attempt code_research_query with the SHA embedded in the URL to see if that bypasses whatever's causing this.

2. github_api_read_only — Show the full current contents of apps/server/src/bootstrap.ts readBootstrapEnvelope function including cleanup() definition and all call sites.

💭 The code_research_query tool is working well with the SHA URL, though the view/git_grep tools have some issues. Since this PR is primarily a bug fix rather than a service refactor, I should focus on whether the touched code actually violates the Effect service conventions—which only apply when a PR creates, moves, refactors, or consumes an Effect service. Let me check the key areas, starting with the imports and the dependency injection setup. I'm noticing the test file imports PlatformError from effect/PlatformError, but I'm not sure if that's a valid module path—it might actually be @effect/platform/Error. However, since this is a test file and the convention is about how Effect library modules are imported as namespaces, I need to verify whether this is a real convention violation or just a potential compile error. The main source changes don't seem to define new services or errors—ensureNodePtyImpl returns plain result objects rather than Effect errors. Let me check the actual source file imports to see if there are any namespace convention violations in the code that's being modified.

3. github_api_read_only — In the branch, list the exact import statements at the top of these three files: apps/desktop/src/backend/DesktopBackendManager.test.ts, apps/desktop/src/wsl/DesktopWslEnvironment.test.ts, and apps/desktop/src/backend/DesktopBackendManager.ts. In particular, is there an import import * as PlatformError from "effect/PlatformError"? Does the module "effect/PlatformError" actually exist in the effect package, or should PlatformError be imported from "@effect/platform/Error" or "@effect/platform"? Also show how PlatformError is used in the test file.

💭 The imports look valid for v4 — effect/testing/TestClock and the subpath imports from effect/unstable/http and effect/unstable/process follow the conventions. Using import * as PlatformError for a type-only reference isn't a violation either, even though named imports would also work for pure types. This PR seems fine so far. I'm realizing there's a tension between the instruction to respond with "All clear" when there are no findings and the requirement to produce JSON output matching the schema. The customer's check instructions take precedence, so I should set the state to success and put "All clear" in the summary field. Let me verify once more that I haven't missed anything—the namespace imports and helper function exports are all fine, not service convention violations. I'm confident there are no actual findings here, so I'll respond with success state and "All clear" as the message.