`folder attach` and `folder replace` contradict each other for a chat on its implicit default workspace

[ijindal1]

Before filing

• I searched open and closed issues for duplicates.
• I reproduced this on the latest release (0.6.2).
• This is one bug, not several bundled together.

Closest existing issue

none found (#134 mentions multi-workspace support, but is about terminal discoverability — a different problem)

What's broken

With multi-workspace support disabled, a chat that has never had a folder explicitly attached cannot be moved to a different folder: berdctl folder attach refuses because the chat "already has a workspace" and recommends folder replace, while folder replace refuses because that same folder "is not attached". The two commands contradict each other, and the chat can't be moved at all.

Steps to reproduce

1. Launch Berd
2. With multi-workspace support disabled (mine is; I haven't changed this setting)
3. Start a chat and never explicitly attach a folder, so it sits on Berd's implicit default cwd. (Mine were chats inside a project that had no working directory configured.)
4. berdctl folder list --session-id <id> → reports one folder entry with "cwd": false, while the top-level "cwd" field is that same path
5. berdctl folder attach --session-id <id> --path <other folder>
6. Following the step-5 error's advice: berdctl folder replace --session-id <id> --old-path <path from step 4> --new-path <other folder>

What you expected to happen

One of them works — either replace accepts the implicit default folder as --old-path, or attach swaps it out when multi-workspace is off, or the step-5 error names a remedy that can actually succeed.

What actually happened

step 5: invalid_args: Multi-workspace support is disabled and this chat
        already has a workspace. Enable it, or use `berdctl folder replace`
        / `berdctl folder set-cwd`.
step 6: invalid_args: Could not replace "/Users/<me>/goose artifacts":
        it is not attached to session "<id>"

attach treats the implicit default as an existing workspace; replace treats it as not attached. The error in step 5 explicitly recommends a command that cannot succeed.

Related minor confusion: folder list reporting "cwd": false on the entry that is the cwd (step 4).

How often does it happen?

Every time — reliably reproducible (identical on three separate chats)

Berd version

0.6.2

Operating system

macOS (Apple Silicon)

Model and provider

Claude Opus and Claude Fable 5 via the Claude Code (claude-acp) harness — though this reproduces entirely through berdctl, with no agent turn involved.

Relevant log output

[2026-08-26][02:46:15][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=folders result=invalid_args duration_ms=119
[2026-08-26][02:46:15][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=folders result=invalid_args duration_ms=93
[2026-08-26][02:46:15][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=folders result=invalid_args duration_ms=86
[2026-08-26][02:46:20][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=folders result=invalid_args duration_ms=45
[2026-08-26][02:46:20][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=folders result=invalid_args duration_ms=40
[2026-08-26][02:46:20][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=folders result=invalid_args duration_ms=41

First three lines are the attach attempts, last three the replace attempts.

---

Filed via gh (an agent helped investigate and draft; I reviewed before posting). Laid out with the bug-report form's fields since the API path doesn't render the form.

[ijindal1]

Re-tested on 0.6.2 today. Both errors still reproduce verbatim.

One thing worth adding: folder set-cwd succeeds where the other two fail, and it accepts a path that was never attached to the chat.

$ berdctl folder set-cwd --session-id <id> --path <folder never attached>
{"ok":true,"path":"<folder>","status":"pending"}

So chats aren't actually immovable, which narrows this. The step-5 error offers three remedies and only the third works, while replace is named first. Separately, set-cwd's own --help describes it as being for selecting an already-attached folder, so the one command that solves the problem is documented as not being for this.