feat: show active project in chat status

[danspicytaco]

Context

Projects are first-class workspaces in the desktop app, but the active chat does not show which project owned the session. Users had to infer it from the sidebar or cwd.

Problem

The chat chrome surfaced cwd and branch, but not the human project name. That made it easy to miss when a session moved into a different project.

Solution

Add project metadata to session.info, mirror it into Desktop state, and render the active project in the Desktop status bar. The TUI status label and /status output now use the same project metadata, so both chat surfaces expose the same workspace identity.

Example of the project website in Desktop status bar

[tonydwb]

Code Review Summary

Verdict: Approved

Overview

Adds project metadata to session.info, mirrors it into Desktop state, and renders the active project name in the Desktop status bar. The TUI status label and /status output now use the same project metadata, unifying workspace identity across chat surfaces.

Changes

• 13 files changed, 184 additions, 7 deletions
• Desktop: status bar, session hooks, store, types
• TUI: path utilities, test fixtures
• Backend: tui_gateway/server.py + RPC test

Assessment

• Correctness: Well-scoped feature, adds project name to status bar without changing session routing.
• Security: No secrets, credentials, or security-sensitive changes.
• Tests: Includes markdown-code.test.ts and paths.test.ts — good coverage for the path/markdown rendering changes.
• Performance: No N+1 or blocking operations.
• Debug artifacts: None found.

Summary

Clean feature addition with good test coverage and clear motivation. No issues.

---

Reviewed by Hermes Agent

[teknium1]

Thanks for carrying first-class project identity through both chat surfaces. The feature premise is confirmed on current main: tui_gateway/server.py:3410-3412 publishes cwd/branch but no project, and ui-tui/src/app/useMainApp.ts:1122-1130 formats only cwd/branch.

Problems

• apps/desktop/src/app/session/hooks/use-session-actions/index.ts:664 applies synchronous resume info through applyRuntimeInfo, but utils.ts:291-299 does not mirror project. The new event handler covers only later session.info emissions.
• tui_gateway/server.py:5972-5976 has an agentless session.cwd.set payload without project. With gateway-event.ts:203-205, that preserves a previous project label after a cwd change.
• $currentProject needs the same reset/reconciliation coverage as cwd and branch; existing draft reset (index.ts:220-230) and gateway wipe (store/gateway-switch.ts:40-59) do not clear it.

Suggested changes

• Thread project through applyRuntimeInfo, all agentless session-info shapes, and state-reset paths; add lifecycle tests for resume and an unowned cwd transition.

Automated hermes-sweeper review.

[danspicytaco]

Thanks for the review @teknium1 ~ pushed fixes for all comments and verified locally.

[OutThisLife]

Thanks @danspicytaco — carrying first-class project identity through both chat surfaces is the right feature, and the backend shape you landed on (resolve the owning project from the per-profile projects.db and thread it through session.info, with the TUI formatting it inline) is sound. I've kept that approach.

Superseding with #67282, with one design change. This PR added a second source of truth on the Desktop — a per-session $currentProject atom fed from session.info — which is what pulled in the whole reset/reconciliation surface (applyRuntimeInfo on resume, agentless session.cwd.set, gateway-switch, fresh-draft), each a place the parallel copy can go stale. The Desktop already caches project truth in $projectTree, so #67282 derives the status label from it (projectNameForCwd) instead of carrying a second copy: the label is purely derived, always correct when the cwd or tree changes, and no reset paths are needed. The TUI keeps your backend field (it has no projects cache), so both surfaces still name a session identically — explicit named projects only.

Also split out the unrelated markdown shell-fence change from this branch; that's worth its own PR if you still want it — ping me and I'll review it.

Closing in favor of #67282. Appreciate the work here.