[Feature]: Allow chats that are not attached to a project or repository

[ElliotDrel]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web, apps/server, thread/project modeling, and provider startup

Problem or use case

T3 Code currently organizes chats around projects, but not every conversation should belong to a repository or working directory.

Sometimes I want to use Claude Code, Codex, or another provider for general reasoning, research, planning, drafting, troubleshooting, or deciding what project to work in before attaching the conversation to any codebase.

Codex supports starting a conversation without selecting a project. I would like the same capability in T3 Code instead of having to create or select an unrelated folder just to begin a chat.

Proposed solution

Add a first-class No project or General chat option when creating a new thread.

The resulting conversation should exist normally in T3 Code but should not be attached to a repository, project, worktree, or user-selected working directory.

Expected behavior

• The new-chat flow includes a visible No project option.
• Projectless chats appear in a dedicated General, No project, or Unassigned section rather than being placed under an unrelated project.
• Users can select the provider, model, permission mode, and other normal thread settings.
• T3 does not inject project-specific repository context, git state, worktree metadata, or project instructions into the provider session.
• The provider starts in a safe neutral working directory managed by T3, rather than silently using an arbitrary existing project.
• Project-only UI such as branch controls, git diff, checkpoints tied to a repository, and worktree actions is hidden or clearly disabled.
• Chat history, plans, tool output, attachments, remote access, and normal conversation controls continue to work where they do not require a project.
• The thread remains visibly marked as projectless so the user always knows it is not operating inside a repository.

Optional follow-up capability

It would be useful to allow a projectless chat to be attached to a project later.

For example:

1. Start a general conversation to explore an idea.
2. Decide which repository should contain the work.
3. Choose Attach to project.
4. Select a configured project and continue the same T3 conversation with that project as the working context.

This should be explicit and should clearly mark the point where project access begins. It is not required for the smallest useful version.

Why this matters

T3 Code is useful as a unified interface for multiple coding-agent providers, but forcing every conversation into a project unnecessarily limits it to repository-first workflows.

A projectless mode would support:

• early planning before choosing a repository;
• general technical questions;
• research and architecture discussions;
• drafting issues, specifications, or prompts;
• troubleshooting that spans multiple projects;
• ordinary conversations where filesystem access is not needed.

It would also prevent users from polluting real projects with unrelated chats or creating meaningless placeholder folders.

Smallest useful scope

• Add No project to the new-thread flow.
• Store and display the thread outside the project hierarchy.
• Start the provider in a T3-managed neutral directory.
• Disable project-specific controls.
• Preserve normal chat functionality that does not require a repository.

Risks or tradeoffs

• Some providers may require a current working directory even when no project is selected, so T3 should create a stable application-managed scratch directory rather than using the user's home directory implicitly.
• File and shell tools need clear boundaries so a projectless chat does not unexpectedly gain broad filesystem access.
• Project-specific features must handle a missing project relationship cleanly instead of assuming every thread has one.
• If a project is attached later, T3 must clearly transition provider context and working-directory state without silently claiming the provider already knew the repository.

[kelchm]

+1 -- as silly as it sounds, this is the number one thing I feel is missing right now.

For now I'm using an empty-project 'sandbox' to get by, but I'd really love to see this as a first-class feature in T3Code.