Desktop app cannot be scoped to a subset of projects

[mathieustan]

What I am trying to do

I want to demo the desktop app to other people without showing every project on my machine. The sidebar and every section list all of them, client work included, and nothing in the UI narrows that down.

What I found looking for a workaround

The README says:

The --project and --exclude flags work on all commands and can be combined with --provider.

That is not the case. Only report, overview, web, status, today, month and export declare them. Seven others do not: sessions, models, compare, audit, optimize, yield and spend.

$ codeburn sessions --project my-company
error: unknown option '--project'

So a filter passed down from the Electron layer only reaches the one status call. The Sessions list keeps showing everything, which is what sent me looking at the CLI in the first place.

The second thing I hit is subtler. filterProjectsByName treats every pattern as a raw substring, so excluding a project by its path also takes out the neighbors that share the prefix:

$ codeburn sessions --exclude=/Users/me/work/my-company
# my-company-kit disappears too

There is no pattern I can type that means this project and not its siblings. isProxiedPath already handles the same problem for proxyPaths by checking a path-segment boundary.

What I would like to propose

The flag gap looks cheap to close. All seven commands already funnel through parseAllSessions, so the existing filterProjectsByName can be applied at that one point. yield and spend parse inside computeYield and computeSpendFlow, which would take the patterns as optional arguments.

For the substring problem, an absolute path (POSIX or Windows drive) would match the way isProxiedPath matches: equal to the project path, or a prefix of it on a path-segment boundary. Anything that is not a path stays the loose substring people actually type, so --project my-company still covers my-company-kit and worktrees. I read this as a bug fix rather than a behavior change, since anyone passing a full path today already gets neighbors they did not ask for.

Then a Projects pane in Settings, one switch per detected project. I put the filter in ~/.config/codeburn/app-filter.json and read it in the main process, since that is where the CLI argv gets assembled and renderer storage never reaches it. No file, or empty lists, means no filter, so nothing moves for anyone who never opens the pane.

Two decisions in there I am less sure about. The pane fetches its own project list without the filter applied, because scoping it would hide the projects the checklist exists to switch back on. And patterns go out as --project=<value> rather than two argv entries, because a Claude project directory is encoded as -Users-me-Web-thing and a leading dash in its own slot parses as a flag.

Before I open a PR

This works locally against my real data on macOS, with tests. Asking first, per CONTRIBUTING: is this a direction you want, and would you rather have it as one PR or split between the CLI side and the desktop side?

If the pane is not something you want in the app, I can contribute just the CLI fixes.

[iamtoruk]

Both findings confirmed on main: the seven commands lack the flags, and filterProjectsByName is a raw substring match. The README line is wrong. Yes to the direction, go ahead.

Please split it: a CLI PR first (flags on all commands via parseAllSessions, path-boundary matching for absolute patterns, README fix), then the desktop Projects pane as a second PR.

Two things for the CLI PR. Build the path match on normalizeAbsProjectPathKey / foldIdentifiedWindowsPath in src/parser.ts (landed in #1271) so Windows folds case and POSIX does not, rather than a second copy of the isProxiedPath logic. And status --scope combined rejects --project today, so the desktop pane will need to decide what the combined view does with a filter.

Your two calls are right: fetch the pane's list unfiltered, and pass --project= as one argv entry.

[mathieustan]

Thanks, split as you asked. The CLI half is up: #1285.

It carries the flags on the remaining seven commands via parseAllSessions, the path-boundary matching, and the README fix. The path match is built on normalizeAbsProjectPathKey / foldIdentifiedWindowsPath from #1271 rather than a second copy of the isProxiedPath logic, so identified Windows paths casefold, POSIX case stays identity, and a Codex-style stripped path (root/vault) keys the same as the /root/vault someone types.

Two things in the PR that need your call, both described there: one pattern shape whose meaning the anchoring changes (a rooted fragment that is not a path from the root now matches nothing), and what the combined view should do with a filter.

On that second one, since it decides the shape of the desktop PR: status --scope combined rejects --project/--exclude, so in the pane I made the filter win. Combined is unavailable while a project filter is set, because dropping the filter instead would put the hidden projects back inside the combined total, which is the one thing the pane exists to prevent. The Projects pane is ready to follow as a second PR on top of #1285; tell me if you would rather combined stayed available and just ignored the filter, and I will flip it before opening.