Bug: orchestration reply can use a stale terminal identity

[shaoxianbilly]

Summary

orca orchestration reply can auto-resolve a from_handle that is not the terminal receiving the message and is no longer present in orca terminal list. This makes replies appear to come from a stale or unrelated terminal identity.

Environment

• macOS
• Orca desktop runtime reachable and ready
• Orca CLI currently prints usage rather than a version for orca --version, so the exact build version is not available from the CLI
• Multiple repos/worktrees and agent terminals open concurrently

Reproduction

1. Open multiple Orca worktrees and terminals.
2. Send an orchestration message directly to terminal term_2d2f77e7-166c-4a2a-b928-138c01368c9e.
3. In that terminal, run:

orca orchestration reply \
  --id msg_e529bd3add28 \
  --body "This terminal is not the task owner" \
  --json

4. Inspect the returned message and run orca terminal list --json.

Expected

The reply should use the receiving/current terminal identity:

from_handle: term_2d2f77e7-166c-4a2a-b928-138c01368c9e

Or the CLI should fail and require an explicit --from if current-terminal identity cannot be resolved safely.

Actual

The reply was created with:

from_handle: term_f1b4b38f-2ab5-483e-8263-eee86dde0a4a

That handle was not present in the subsequent orca terminal list --json output. The receiving terminal was still present and mapped to its expected worktree.

Relevant message metadata, with content and local paths omitted:

{
  "id": "msg_e529bd3add28",
  "to_handle": "term_2d2f77e7-166c-4a2a-b928-138c01368c9e",
  "type": "status",
  "priority": "high"
}

Reply result:

{
  "from_handle": "term_f1b4b38f-2ab5-483e-8263-eee86dde0a4a",
  "to_handle": "term_a6743d1b-8985-465d-9b9a-ccac2063b4f9",
  "type": "status"
}

Impact

• Coordinators cannot reliably identify which terminal responded.
• Task ownership and claim resolution can be attributed to the wrong agent.
• Dispatch-scoped messages such as worker_done, heartbeat, and decision-gate replies may be associated with stale identities.
• The risk is higher after app/runtime restarts or terminal recreation.

Suggested behavior

• Resolve identity from the terminal executing the CLI command, not a stale session-level handle.
• Verify the resolved handle is currently live and belongs to the current pane/worktree.
• If identity is ambiguous or stale, fail closed and ask for --from.
• Include current terminal/worktree identity in debug output for reply commands.