fix: improve project favicon detection for monorepos

[ponbac]

The XXL tag seems a little weird for this PR? It is a net +288 LoC, excluding test files.

What Changed

Improve project favicon detection without introducing a broad recursive search.
Closes #1020.

Rules, in order:

• Check well-known favicon paths in the requested project root.
  Example: /repo/favicon.svg or /repo/public/favicon.ico.
• If none exist, look for <link rel="icon" ... href="..."> tags or object-style { href, rel: "icon" } declarations in a small set of common source files, then resolve that target.
  Example: /repo/index.html points to /brand/logo.svg, so the route first tries /repo/public/brand/logo.svg and then /repo/brand/logo.svg.
• If still nothing is found, repeat the same checks for first-level children of apps/ and packages/, plus other top-level directories in the requested root, using the same non-git directory ignore rules as workspaceEntries.
  Example: /repo/apps/web/public/favicon.png or /repo/frontend/public/favicon.png is found when the cwd is /repo.
• Prefer a root match over nested workspace matches.
  Example: /repo/favicon.svg wins over /repo/apps/web/public/favicon.ico.
• Fall back to the existing generated SVG when nothing is found.

I also extracted the shared gitignore probing into apps/server/src/gitIgnore.ts so both workspaceEntries and projectFaviconRoute use the same chunked git check-ignore --no-index -z --stdin filtering. I also extracted the shared workspace directory ignore policy into apps/server/src/workspaceIgnore.ts, so projectFaviconRoute now uses the same non-git skip rules as workspaceEntries when scanning nested roots instead of keeping a separate ignore list.

Why

The current behavior misses common monorepo layouts where the favicon lives under an app directory instead of the repo root.

There was already an earlier PR for this in the upstream repo: #690. That version was larger and messier. This keeps the rules simple on purpose, leaving more extensive changes to project icons for trusted maintainers.

UI Changes

Not applicable.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Note

Improve project favicon detection to support monorepos with gitignore filtering

• Rewrites ProjectFaviconResolver.resolvePath to search nested apps/, packages/, and top-level child directories when no root favicon is found, enabling monorepo support.
• Adds gitignore-aware filtering via new gitIgnore.ts utilities (filterGitIgnoredPaths, isInsideGitWorkTree) that stream candidates to git check-ignore in 256 KiB chunks.
• Introduces workspaceIgnore.ts to skip well-known directories (.git, node_modules, .next, dist, etc.) during directory traversal.
• Adds workspaceEntries.ts for a cacheable, git-backed or filesystem-fallback workspace index with fuzzy-ranked search.
• Fixes a missing FileSystem service injection in the static file handler in wsServer.ts that previously caused runtime errors.
• Behavioral Change: resolver now fails open on filesystem or git errors (treats unreadable paths as misses) rather than throwing.

📊 Macroscope summarized 7404ccc. 7 files reviewed, 2 issues evaluated, 0 issues filtered, 1 comment posted

🗂️ Filtered Issues

---

Note

Medium Risk
Modifies server-side favicon resolution and adds git-driven ignore filtering/search across workspace roots, which could affect file discovery performance and edge cases around path/permission handling. Git/process failures are handled fail-open, reducing risk of hiding files but still changing behavior.

Overview
Project favicon resolution is expanded to better support monorepos. The resolver now checks well-known favicon paths and icon metadata in common source files in the requested root, then repeats the same checks across first-level apps/, packages/, and other top-level directories (skipping ignored workspace dirs), preferring root matches before falling back to the generated SVG.

Gitignore-aware filtering is added and shared. New gitIgnore.ts provides isInsideGitWorkTree and chunked filterGitIgnoredPaths (git check-ignore --no-index -z --stdin) with fail-open behavior; both the favicon resolver and the new workspaceEntries.ts use this to avoid considering gitignored candidates.

Testing and wiring updates. New unit tests cover gitignore chunking/fail-open and expanded favicon route scenarios (nested roots, unreadable files, gitignored root/app/source cases), and wsServer.ts now provides FileSystem to the static-file handler Effect pipeline.

^{Written by Cursor Bugbot for commit 7404ccc. This will update automatically on new commits. Configure here.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. 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.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 1d0c0481-2c6f-4031-889c-b7db1c6902ee

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

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a4a8d330eb

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[eddieajau]

My 2c

getIgnore.ts should be separated into individual commands for isInsideGitWorkTree, filterGitIgnoredPaths. You've done the right think pulling it out, but it could go further.

I would add unit tests for this file rather than relying on integration tests.

Since this is a new file, I would also add some solid docblocks to provide good human and AI context for the decisions being made. Hopefully the reviewers will pick that up and think it's a good idea for their code standards.

[ponbac]

My 2c

getIgnore.ts should be separated into individual commands for isInsideGitWorkTree, filterGitIgnoredPaths. You've done the right think pulling it out, but it could go further.

I would add unit tests for this file rather than relying on integration tests.

Since this is a new file, I would also add some solid docblocks to provide good human and AI context for the decisions being made. Hopefully the reviewers will pick that up and think it's a good idea for their code standards.

Not sure about separating them right now, but I also feel like isInsideGitWorkTree() should live somewhere else. It does not really have anything to do with .gitignore.

I agree with the unit tests, added now.

Also added an explanatory comment to the filterGitIgnoredPaths(). I should maybe add additional ones, but I am not sure what is preferred here.

[cursor]

orElseSucceed cannot catch Effect.promise defects

Low Severity

Effect.promise converts promise rejections into defects (unchecked exceptions), but Effect.orElseSucceed only catches expected (typed) errors. The fallback () => uncachedRelativePaths is unreachable — if filterGitIgnoredPaths ever rejects, the defect propagates instead of gracefully falling back. Compare with the isInsideGitWorkTree call at line 392–393, which correctly uses .catch(() => false) on the promise itself before wrapping with Effect.promise. Using Effect.tryPromise here instead of Effect.promise would make orElseSucceed actually effective.

 

[macroscopeapp]

🟢 Low src/workspaceEntries.ts:425

clearWorkspaceIndexCache deletes entries from workspaceIndexCache and inFlightWorkspaceIndexBuilds, but any in-flight buildWorkspaceIndex promise (already spawned before the clear) will still execute its .then() handler and repopulate workspaceIndexCache after the function returns. This means a caller who clears the cache to force a fresh rebuild may unexpectedly receive stale data from the completing in-flight build instead of a new index.

🤖 Copy this AI Prompt to have your agent fix this:

In file apps/server/src/workspaceEntries.ts around line 425:

`clearWorkspaceIndexCache` deletes entries from `workspaceIndexCache` and `inFlightWorkspaceIndexBuilds`, but any in-flight `buildWorkspaceIndex` promise (already spawned before the clear) will still execute its `.then()` handler and repopulate `workspaceIndexCache` after the function returns. This means a caller who clears the cache to force a fresh rebuild may unexpectedly receive stale data from the completing in-flight build instead of a new index.

Evidence trail:
- apps/server/src/workspaceEntries.ts lines 408-421 (REVIEWED_COMMIT): Promise creation with `.then()` handler that unconditionally sets `workspaceIndexCache.set(cwd, next)`
- apps/server/src/workspaceEntries.ts lines 425-428 (REVIEWED_COMMIT): `clearWorkspaceIndexCache` deletes from maps but cannot cancel the running promise
- apps/server/src/workspaceEntries.ts lines 34-35 (REVIEWED_COMMIT): Cache definitions as module-level Maps

[cursor]

Cursor Bugbot has reviewed your changes and found 2 potential issues.

There are 3 total unresolved issues (including 1 from previous review).

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Entire new file is dead code, never imported

Medium Severity

The entire 453-line workspaceEntries.ts file is dead code. Its exports clearWorkspaceIndexCache and searchWorkspaceEntries are not imported anywhere in the codebase. The file duplicates nearly all logic from apps/server/src/workspace/Layers/WorkspaceEntries.ts (the Effect-based service version) using raw async functions instead. All existing consumers continue to use WorkspaceEntriesLive from workspace/Layers/WorkspaceEntries.ts.

 

[cursor]

Favicon probe reads entire file content unnecessarily

Low Severity

findFirstReadableFaviconPath calls readFileIfExists with readFile (full binary read) for each favicon candidate, but only uses the resulting path — the file content is discarded. Since resolveExistingPath already confirms the file exists via realPath and stat, the full content read is redundant. The route handler in projectFaviconRoute.ts then reads the same file again to serve it, doubling I/O for potentially large PNG/ICO files.