A working directory is a useful way to group agent chats until one piece of work spans several repositories—or two different pieces of work use the same repository.
AIClaw 3.7.28 adds an explicit project layer to the desktop sidebar. A project has its own name and identity, can list multiple working directories, and can contain conversations independently of their execution location.
This shipped in v3.7.28. At this review, v3.7.30 is the latest public release. The behavior described here is already released, rather than a proposal or an unreleased branch feature.
One project, one directory per conversation
The earlier workspace article described grouping conversations by their saved directory. That remains a useful fallback. The new feature addresses a different relationship: a named project can outlive any one folder choice.
For example, an illustrative project called “Checkout redesign” might list:
/work/store-api
/work/store-web
Start one conversation in the API directory and another in the web directory. Both can appear under the same project, while each conversation still has one working directory.
This is not a multi-root execution environment. Adding two directories does not make a single conversation run in both, and moving a chat into a project does not silently change its existing working directory.
Identity is separate from the path
The sidebar helper builds explicit project buckets first. Conversation assignments use the project ID, so two projects can share a directory without merging their chats. An empty project also remains visible before its first conversation exists.
Unassigned conversations with saved directories continue through the existing full-path workspace grouping. The implementation does not require users to classify every old chat before the sidebar works.
This distinction lives in projectBuckets: project membership determines the explicit bucket; the directory still describes where the conversation executes.
Choose the location before starting work
Project settings show the configured directories as a list, mark the first as the default, and let users add folders through the directory picker or remove individual entries.
The project input normalizer trims names and paths, removes empty and duplicate path strings, and preserves directory order. The host additionally requires absolute paths and rejects embedded null characters. This is input validation, not filesystem canonicalization: equivalent symlink paths are not automatically deduplicated.
When creating a project conversation, the host resolves the selected directory against that project's configured list. An explicit choice outside the list is rejected by this creation path. Without an explicit choice, it uses the first directory.
A project with no configured directories falls back to an aiclaw folder inside the user's home directory. New-session startup creates the working directory recursively when needed. The fallback also applies to new ordinary chats with no selected workspace; existing chats retain their saved location.
The relevant sources are projects.ts, workspace-defaults.ts, and the desktop session handlers.
Organization should not relocate existing work
Starting a conversation under a project records its project assignment after session creation. Forking a conversation copies its assignment when the referenced project still exists.
Changing membership updates that relationship without moving files. Editing the project's directory list also does not rewrite the directories saved on existing conversations.
Removing a project removes its definition and membership references. The handler does not delete the member conversations or their files. Conversations with a saved directory can then appear in the fallback workspace grouping.
These operations organize navigation. They do not create a filesystem sandbox, a new permission policy, or a separate copy of a repository. Two projects pointing to the same directory still point to the same files.
What was verified
For this article, I reran five focused project/workspace test functions against the clean v3.7.30 checkout. All five passed, with zero failures or skips.
The checks cover ordered directory normalization and invalid input, first-directory and home-directory fallbacks, rejection of an unconfigured directory at project chat creation, full-path identity, directory display names, and independent membership for projects sharing a directory. They also check that an empty project remains visible and legacy entries without explicit project directories fall back to workspace grouping.
The tests are in test-config.ts and test-workspace-buckets.ts. The three helper source files discussed above matched the public v3.7.28 versions byte for byte.
These are local helper regressions. They do not exercise a real operating system folder picker or prove every desktop workflow. The v3.7.28 release notes separately report broader checks, including multi-directory configuration, renderer reload, membership, and starting a chat in the selected directory; I did not rerun that full suite for this article.
The useful boundary is simple: a project answers which work a conversation belongs to, while its working directory answers where the agent starts executing. Keeping those decisions separate lets a project span repositories without silently relocating an existing chat.
Top comments (0)