berdctl session create should inherit the spawning session’s project

[gregp-squareup]

Before filing

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

Closest existing issue

221

What's broken

When a chat that belongs to a Berd project spawns a new chat through
berdctl session create, the child does not reliably inherit the spawning
chat’s project.

If --project-id is omitted(optional parameter), the child can be filed under the active app
project instead of the parent chat’s project. This is easy to miss when the
app is currently viewing a different project.

That breaks project-scoped coordination. A parent and its worker can appear in
different project views even though the worker was created specifically for
that parent’s work.

Steps to reproduce

1. Open or run a chat that belongs to Project A.
2. Change the active Berd app project to Project B, or otherwise make another
   project active.
3. From the Project A chat, run berdctl session create without
   --project-id.
4. Observe that the created child is not reliably assigned to Project A.

What you expected to happen

When berdctl session create runs from a Berd chat, the default project should
be the spawning chat’s project_id.

Explicit --project-id should continue to override that default.

What actually happened

It inherets the currently selected project in Berd UI (not the project of the session it was created from)

How often does it happen?

Every time — reliably reproducible

Berd version

0.5.19

Operating system

macOS (Apple Silicon)

Model and provider

GPT 5.6 Terra

Relevant log output

Environment:
- Berd 0.5.19
- macOS (Apple Silicon)
- Updated through the Berd UI on 2026-08-28

Reproduction command:

berdctl session create \
  --prompt '[Berd project inheritance reproduction test] This is a no-work test session. Reply only: Test complete.' \
  --harness-id goose \
  --json \
  --timeout-ms 30000

Result:

{"harness_id":"goose","send_status":"dispatched","session_id":"20260828_17","title":"New chat"}

Created-session metadata:

{
  "session_id": "20260828_17",
  "project_id": null,
  "is_running": true,
  "chat_state": "streaming",
  "title": "New chat",
  "updated_at": "2026-08-28T12:59:51+00:00"
}

The initiating Berd session belonged to project_id "my-berd-project".
The new session was created without --project-id and received project_id null.

Relevant sanitized Berd app-log lines:

[2026-08-28][12:59:48][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=info result=ok duration_ms=114
[2026-08-28][12:59:51][berd_lib::commands::renderer][INFO] [renderer] [reasoning-effort] acpCreateSession newSession response {"sessionId":"20260828","providerId":"databricks_v2","requestedModelId":"goose-gpt-5-5","providerSetupDeferred":false,"hasReasoningEffortSnapshot":true}
[2026-08-28][12:59:51][berd_lib::commands::renderer][INFO] [renderer] [reasoning-effort] createSession acp resolved {"sessionId":"20260828","providerId":"goose","modelId":null,"hasReasoningEffort":true}
[2026-08-28][12:59:51][berd_lib::commands::renderer][INFO] [renderer] [reasoning-effort] createSession inserted {"sessionId":"20260828","providerId":"goose","modelId":null,"hasReasoningEffort":true}
[2026-08-28][12:59:51][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=sessions result=ok duration_ms=3293
[2026-08-28][12:59:55][tauri_plugin_berdctl::server][INFO] [berdctl] /v1/call command=sessions result=ok duration_ms=237

No error was emitted in berd.log during this reproduction. The unexpected behavior is the created session's project_id being null rather than inheriting the initiating session's project.

Screenshots, recordings, or other context

No response