fix(claude): report unauthenticated Claude instances honestly - #8275

💭 I'm reviewing the changed files for convention issues—checking the Effect imports in ClaudeProvider.ts, usage patterns like Effect.result and Result.isFailure, a duplicated docblock comment, and how HostProcessPlatform is imported as a service tag. I'm also looking at the catchCause fallback handling to see if it's swallowing errors silently.

1. browse_code — apps/server/src/provider/Layers/ClaudeProvider.ts

2. browse_code — In packages (or wherever) @t3tools/shared/hostProcess is defined: show the module source, especially HostProcessPlatform — is it a Context.Reference/Context.Service tag? Also show how other modules import it (named vs namespace import).

💭 Imports look fine. Now I'm checking the new code added around lines 800-1130 in the file.

3. browse_code — apps/server/src/provider/Layers/ClaudeProvider.ts

💭 I notice a duplicated JSDoc comment block that's now misattached to the wrong function, quoteForShell — a stale copy-paste artifact rather than a true convention violation, so it's a minor issue worth flagging rather than a hard rule break. Then I check resolvedEnvironment = environment ?? process.env and confirm it's pre-existing, untouched by the diff, so it's out of scope for review. Looking at probeClaudeAuthStatus, I notice it uses Effect.catchCause to swallow all failures including interruption, which conflicts with the convention of preserving interruption during startup reconciliation rather than reducing it to a mere warning. I also verify that checkClaudeProviderStatus and claudeLoginHint have correct requirement types, since HostProcessPlatform is a Context.Reference and doesn't add extra dependencies, and that the test file properly provides HostProcessPlatform as "win32" for the PowerShell test case.

4. browse_code — apps/server/src/provider/Layers/ProviderRegistry.test.ts

5. git_tools — resolveClaudeHomePath|AUTH_PROBE_TIMEOUT_MS

💭 I'm checking whether passing a raw number instead of a Duration to the timeout function is valid, and confirming Effect's Duration input treats plain numbers as milliseconds, so it should work fine. I also want to check how ClaudeProvider defines its capabilities probe timeout for consistency. Looking further, I notice a duplicated JSDoc comment block sitting oddly above quoteForShell — a small leftover defect from the PR, though not tied to any Effect service convention, so I'm weighing whether it's worth flagging as a minor note rather than a failing issue. I'm also examining a catchCause handler that swallows both defects and interruption, which conflicts with the guidance to preserve interruption except during startup reconciliation. I'm also scanning for other typical antipatterns — untyped errors being caught broadly instead of via catchTags, raw process.env usage, service-instance parameters, or improper use of Layer.succeed, ManagedRuntime, or runPromise — but the new code appears clean on all these fronts. I want to confirm the test file relies on the existing mock spawner layer rather than introducing new dependency-injection antipatterns, and that no large tests were added purely to validate what looks like a mechanical refactor. The remaining question is whether inconsistent use of Effect.fn versus plain Effect.gen across similar helpers counts as a real convention violation or just a style preference, and I'm leaning toward the latter since it isn't on the explicit list. I'm concluding there are no real Effect service convention violations here—the duplicated JSDoc is a minor defect but not a failure to preserve documentation. Given the instructions specify responding exactly "All clear" if nothing concrete is found, but also require a JSON schema output, I'm noting the tension between those two formatting requirements.

6. git_tools — quote|shellQuote

7. git_tools — const mockSpawnerLayer

💭 I'm checking whether mockSpawnerLayer is already defined elsewhere in the test file rather than needing new setup. Double-checking there's no hidden runtime or global state introduced, confirming the process.env usage in checkClaudeProviderStatus is pre-existing, and considering whether Effect.catchCause might be silently swallowing errors. The catchCause usage intentionally handles both errors and defects, which is documented and matches the convention that catching the entire error channel is fine when deliberate. I notice a duplicated JSDoc comment but decide that's a stylistic nit outside the scope of Effect service convention review, so I'll conclude the code is clean per the specific conventions being checked.