feat(code): top-level app nav rail (Home / Inbox / Code)

[adamleithp]

Dev-only for now

This is gated behind the project-bluebird feature flag and is not enabled for any real users. It only shows up for people who have the flag turned on — i.e. us, internally, while the Home space is built out.

• Flag on (default in dev builds, plus anyone we explicitly target): the app rail appears with Home / Inbox / Code.
• Flag off (every prod user today): the app is byte-for-byte the current code-only shell — no rail, / and /inbox redirect to /code, and the Code chrome is untouched.

So merging this is a no-op for users until we deliberately flip the flag. It's safe to land and iterate on behind the flag.

What

Adds a Slack-like vertical app nav rail that switches between three top-level spaces:

• Home — empty placeholder for now (this is what we're still building).
• Inbox — the existing inbox, full-screen.
• Code — the existing app, unchanged.

This is the minimal top-nav extraction from the larger canvas branch — none of the canvas / dashboards / channels machinery comes along.

Changes

• components/AppNav.tsx — the rail: active-space highlighting, the inbox actionable-report badge (useInboxSignalCount, reuses the inbox feature's existing query — no extra polling), and 2.5rem top padding to clear the titlebar.
• routes/index.tsx — / renders an empty Home space (was a redirect → /code).
• routes/inbox.tsx — new top-level route mounting the existing InboxView.
• routes/__root.tsx — renders the rail (only when the flag is on) and branches Home/Inbox to a chrome-less Outlet; Code keeps its existing chrome. Redirect guard sends stranded rail-only paths to /code once flags resolve when the flag is off.
• shared/constants.ts — PROJECT_BLUEBIRD_FLAG.
• hooks/useFeatureFlag.ts — useFeatureFlagsLoaded() so the redirect waits for a trustworthy flag value rather than the pre-load false default.

Testing

• pnpm --filter code typecheck — clean.
• Biome — clean.
• Did not run the Electron app in this environment.

---

Created with PostHog Code

[greptile-apps]

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
apps/code/src/renderer/components/AppNav.tsx:38-45
**Code item active-state gap for sibling top-level routes**

`/command-center`, `/mcp-servers`, and `/skills` are rendered as root-level routes (not under `/code/`), so when a user navigates to any of them with the rail visible, no item in the rail is highlighted. Since `isRailSpace` is false for these paths, the Code chrome (header/sidebar) also renders alongside the rail, meaning the user is visually inside the Code context with an unlit Code button. Extending the `isActive` predicate to cover these paths (or alternatively treating them as non-rail-space paths and hiding the rail) would keep the active state consistent.

_{Reviews (1): Last reviewed commit: "feat(code): top-level app nav rail (Home..." | Re-trigger Greptile}

[greptile-apps]

Code item active-state gap for sibling top-level routes

/command-center, /mcp-servers, and /skills are rendered as root-level routes (not under /code/), so when a user navigates to any of them with the rail visible, no item in the rail is highlighted. Since isRailSpace is false for these paths, the Code chrome (header/sidebar) also renders alongside the rail, meaning the user is visually inside the Code context with an unlit Code button. Extending the isActive predicate to cover these paths (or alternatively treating them as non-rail-space paths and hiding the rail) would keep the active state consistent.

Prompt To Fix With AI

This is a comment left during a code review.
Path: apps/code/src/renderer/components/AppNav.tsx
Line: 38-45

Comment:
**Code item active-state gap for sibling top-level routes**

`/command-center`, `/mcp-servers`, and `/skills` are rendered as root-level routes (not under `/code/`), so when a user navigates to any of them with the rail visible, no item in the rail is highlighted. Since `isRailSpace` is false for these paths, the Code chrome (header/sidebar) also renders alongside the rail, meaning the user is visually inside the Code context with an unlit Code button. Extending the `isActive` predicate to cover these paths (or alternatively treating them as non-rail-space paths and hiding the rail) would keep the active state consistent.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[raquelmsmith]

Hmmmm I'm not convinced we need this. Why add another sidebar instead of just using the inbox item in the existing left sidebar?