[FEATURE] Task-first sessions: infer the working directory instead of requiring it up front (Claude Desktop, local Code)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Starting a local Code session requires choosing a working directory before the task can be
described. That ordering is backwards. A user knows WHAT they want to do before they want to
think about WHERE it lives, and the folder is a detail the assistant is usually better placed to
work out than the human is.

The cost of that up-front choice scales with the size of the workspace, and it is paid on every
single new task. On this machine there are more than 100 projects and over 200 folders Claude has
worked in. Picking from that is now the slowest step in starting work — routinely slower than
writing the task itself.

It also breaks the most natural way to use the product. When several things come to mind at once,
the obvious move is to fire off several new tasks in a row and let them run. That is impossible
today, because each one interrupts you with a folder decision first. So the friction is not just
per-session overhead; it discourages the queue-up-work pattern that the Desktop app is otherwise
very good at.

Worth noting that the terminal CLI does not have this problem: you are already in a directory, so
the working directory is implicit. The Desktop app converted something implicit into a required
modal step, and the pain grows with every project you add.

The picker's own list quality also degrades at this scale — see #86181, where deleted folders
persist in the list forever and the same folder appears several times under different path
spellings.

Proposed Solution

Task first, folder inferred, always visible, one click to correct.

1. Let a new task start with no folder at all. The composer accepts the task description

immediately.

1. Before the first tool call, Claude proposes a working directory and shows it inline as a single

confirm-or-change chip, for example:
Working in ~/Projects/products/nasir · change

1. Rank candidates from signals that are already on disk locally — no new data collection:

• explicit mentions in the task text: a project name, a repo name, a path, a filename
• session history in ~/.claude/projects: which folder past sessions on this topic used
• recency and frequency per folder
• git repository roots and their remote names
• project names declared in CLAUDE.md files

1. When confidence is low, show a short ranked shortlist WITH the reason beside each candidate

("mentions nasir", "used 2 hours ago", "matching repo name") instead of an alphabetical
filesystem tree. A reason makes a three-item list decidable at a glance; a tree of 200 folders
is not.

1. Learn from corrections. If the user changes the inferred folder, remember that pairing and

weight it next time.

Guardrails, so this stays safe:

• The inference picks the DEFAULT, never the permission. The chosen folder is always shown

before anything runs.

• Only already-trusted workspace roots are ever candidates; inference must not reach outside

them.

• Read-only tools may run in the inferred folder; the first write requires the folder to have

been confirmed at least once for that task.

Alternative Solutions

Cheaper wins, in increasing order of effort. Any of them would already help a lot, and they
compose with the full proposal above rather than competing with it.

1. Type-to-filter fuzzy search over known project folders in the existing picker, ranked by

recency, instead of navigating a filesystem tree. This alone removes most of the pain and is
by far the cheapest change.

1. A "Choose for me" button inside the existing picker — same inference, but opt-in per session,

so nothing about the current default flow changes.

1. A user-declared workspace root (for example ~/Projects) that the app indexes once, so the

picker offers PROJECTS rather than directories.

1. Remember the last folder and offer it as a one-key default for the next new task.

Note on prior art: #67249 asked for a cache of the last 3-4 working directories in the
new-session picker (closed). This request is the generalisation of that idea. At 200 folders a
four-item most-recently-used list is not enough — what is needed is ranking over everything, and
ideally no picker step at all.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

A concrete morning, with real numbers from this machine: 100+ projects, 200+ folders Claude has
worked in.

Today:
I think of five things to hand off. For each one I click New task, wait for the picker, navigate
or scroll to the right folder among 200, confirm, and only then type the task. Four of the five
ideas are cheap to describe and expensive to route. By the third one I have lost the thread of
the fourth.

With this feature:
I click New task and type "fix the stale badge in the nasir readme". Claude answers
"Working in ~/Projects/products/nasir · change" and starts. I do not touch the picker. I repeat
four more times in under a minute, and correct the folder on the one it guessed wrong — which
it then remembers.

The saving per task is maybe fifteen seconds. Across a day of many small tasks it is the
difference between handing work off as I think of it and batching it until I have the patience for
the picker.

Additional Context

Related open issues, all pointing at the same area from different angles:

• #73928 Desktop App: allow choosing working directory before first message
• #78851 Desktop app: keyboard shortcut to select working directory (keyboard-only workflow)
• #86181 Folder picker keeps deleted folders forever, and duplicates the same folder by path

spelling

• #67249 (closed) cache and show the last 3-4 working directories in the new-session picker

Technical note: every signal the ranking needs is already local. Session history lives in
~/.claude/projects, git roots and remotes are on disk, and CLAUDE.md files already declare project
names. No new telemetry, no server round trip, and the inference can be a purely local heuristic
before it is ever a model call.

Scope note: this is specifically about the LOCAL Code flow in Claude Desktop. The GitHub-repo flow
has the same shape of problem but a different candidate set, and is probably worth treating
separately.