[liugddx]

Summary

Follow-up to #6464. Opening the Bot asked the user to open a conversation first, so that the Bot could be created in that conversation's workspace ("Open a conversation first; the Bot starts in its workspace."). Clicking Maka Bot should work on its own.

openBot now takes an optional workspace. When it is absent, the Host creates the Bot Session in its first configured workspace root; if the Host has none, it answers no_workspace and releases its claim. The sidebar entry calls openBot with no arguments, and the now-unused prompt and its translations are removed. An explicit workspace still works as before.

Verification

• New test the_bot_opens_without_naming_a_workspace: with no other conversation and no workspace given, openBot creates the Bot in the first root (directories query, root 1), a second open returns the same Bot with created: false, and the Bot sees SendUser. cargo test -p maka-agent-native --lib bot_tests: 13 pass, run in parallel.
• cargo test -p maka-app-client --lib: 25 pass. Workbench tests: 37 pass. cargo clippy --no-deps -p maka-agent-native -p maka-agent-api -p maka-app-client --tests -- -D warnings, cargo fmt --check, npm run schema:check and the @maka-agent/plugin-sdk / @maka-agent/product type checks pass.
• Checked by hand on macOS: from a fresh data directory with no conversations, Maka Bot opens the Bot directly. (Desktop was built from this change's parent branch plus the same diff; the final rebased tree was not launched.)

Not run: just check as a whole; the cua / mxc git dependencies were built from source archives through local path overrides that are not part of this PR. UI files have no repository type check.

Review focus

• owner/bot.rs: default_bot_workspace and the no_workspace path, which releases the claim so a later open can retry.
• Whether the first configured root is the right default, or whether the Bot should get a dedicated directory under the Host's managed area.

AI use

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code (Claude Opus 5.5) wrote the change and its test under my direction; the commit carries a Generated-by trailer.

Checklist

• Tests cover the change and fail without it

🤖 Generated with Claude Code

[Astro-Han]

Automated review notice: This comment was posted by an automated review agent. It is not an independent human review and does not replace one.

I reviewed all seven changed files at e868228f6eac69f27192c5953c7b6f123c9789eb, plus the Bot creation/claim flow, the workspace roots query and surrounding UI command routing. The previous command rejected opening the Bot when no conversation was selected; allowing the Host to resolve the initial workspace addresses that dependency.

I found no confirmed P0–P2 in this scope. Nine schema and controlled UI-function checks passed. The actual generated JSON schemas accept omitted/null workspace and preserve an explicit Session selection, reject malformed input, and admit the new no_workspace output; the old schemas reject the newly admitted forms. The actual commandBot fragment now sends openBot({}) without a selected conversation, while the old fragment reports its former prerequisite error. Other checks cover a selected ordinary conversation, an existing or refreshed Bot, lookup failure, a rejected open, created:false, a dead surface and a command refused by an overlay. The schemas were evaluated with Python's Draft 2020-12 validator without a format checker. Host/control, signals, lifecycle and navigation were controlled adapters.

From the Rust source, an existing unarchived Bot returns before default-workspace resolution. An explicit workspace still goes directly to creation. With no workspace, the new helper uses the first root returned by the published roots query; if no root is returned, the code releases this operation's claim before returning no_workspace. The roots query can omit roots it cannot expose, so this is the first returned usable root rather than a guaranteed fixed directory regardless of root availability. The UI now makes that default choice even when an ordinary conversation is selected. The Bot's tool grants are unchanged. I did not execute Rust root discovery, claim persistence/release, concurrent creation, restart recovery or a real Host open.

All four changed TS/TSX files passed a syntax-only Biome 2.5.9 parse. git diff --check and a real merge-tree against rust-preview f2d7b5c9dbd489053f127f834b823e96363cd765 passed. The service input and rejection enum change is reflected in the checked JSON schema and generated method types; no transport-frame or database migration file changes here. The exact PR head has no hosted checks at publication.

I did not run the Rust schema generator, full TypeScript project, Rust/NSH compilation or native UI. The author's test and macOS results remain author-reported, including the stated difference between the manually launched tree and the final rebased tree.

---

Automated review notice: This comment was posted by an automated review agent operated by Astro-Han. It is not an independent human review and does not replace one.