New Projects UI has no path to start a local-folder session — blocks greenfield development
The core problem: The new "project" concept removes the primitive developers rely on — a folder is the project; point a session at it and start building. There is no way to create a project tied to a new or empty local working directory.
Repro:
- New project → Context → "+ Add" → select a new/empty local folder
- Hard error: "No files were found in what you added. Add files, or a folder that contains files."
- There is no alternative control in that dialog to bind the project to a local working directory.
Why this is the core issue for developers, not an edge case:
- The default development workflow is greenfield + local: make a folder, start working. Projects are cloud-first — you can't add a session you started on your own machine to a project, and "Context" is read-only reference material (first 100 files, no hidden files, no
node_modules). So the most common dev starting point has no home in the new UI. - The local-session capability still exists (the CLI and existing sessions use it), but its UI entry point is buried behind a Projects-first flow and undocumented. Users get funneled into "New project," hit the wall, and conclude new-project development is broken.
- The abstraction optimizes for coordinating cloud work on existing repos, and in doing so hides the folder-is-the-project model technical users depend on.
Added cost dimension: the cloud-first model also pushes developers toward paid cloud sessions for work that runs locally on their own hardware for free. Someone who just wants to build in a local folder shouldn't be funneled toward metered cloud compute to do it.
What good looks like: a first-class, visible "New session in folder" that accepts a new or empty directory, without routing through reference-file upload or GitHub-connect. Folder = project.
Impact: anyone starting a local project from scratch — the common case, not an edge case.