Skip to content

fix(claude): discover native sessions in Orca account-scoped profiles #317

Closed

Description

@abruption

Problem

An active native Claude Code TUI launched by Orca can be silently absent from session-peer list --json, even though its native inbox socket and session registration exist. The Claude process uses an account-scoped Orca profile, while the process running session-peer uses the default Claude configuration directory.

Priority: P2. Consider for the next patch after compatibility/safety review; no implementation, merge, publication or release date is authorized by this issue.

Observed evidence (2026-10-19)

  • macOS arm64, installed Python session-peer 1.1.2, native Claude Code 2.1.303.
  • The native Claude process had the intended project as its cwd. Orca reported its terminal connected and not orphaned; the owner had successfully submitted work through Orca's terminal path.
  • A matching live native inbox socket existed. The matching numeric-PID JSON record was under:
    $HOME/Library/Application Support/orca/claude-profiles/<profile-id>/home/sessions/.
  • The Claude process's CLAUDE_CONFIG_DIR selected that account-scoped home directory.
  • Default Claude listing and --all showed unrelated default-home sessions but omitted the target.
  • A one-command CLAUDE_CONFIG_DIR override to the actual profile made the target appear with the expected cwd and alive: true, reachable: true.
  • Inspection was read-only: no native message, terminal input, restart or configuration change was performed. Only selected configuration-directory variables were extracted from process metadata; the raw command/environment block was not printed or persisted. Credential files and transcripts were not opened. Discovery success does not prove delivery or ACK.

The live reproduction used 1.1.2. The Claude discovery module is byte-identical between published 1.1.2 (f3993bf8988dd301b7e14402e63e8ac04e5e2300) and 1.2.0 (4fc526f36afc65bb6ec460439eb0986c09ecc8ee); upgrading alone does not introduce account-profile discovery. This is source comparison, not a new 1.2.0 native experiment.

No private hostnames, project paths, profile/session identifiers, inbox credentials or conversation content are included here.

Cause

sessions_dir() / discover() at the published 1.2.0 source inspect exactly one root:

  1. CLAUDE_CONFIG_DIR, if explicitly present;
  2. otherwise ANTHROPIC_CONFIG_DIR;
  3. otherwise $HOME/.claude.

Known Orca claude-profiles/*/home roots are not inventoried. --all only includes valid unreachable records from the selected root; it does not search other roots. There is no cwd filter, so spaces in the project path are not the cause. Orca PTY routing and native Claude inbox discovery are separate mechanisms.

Minimal reproduction / workaround

  1. Run Claude through Orca with an account-scoped CLAUDE_CONFIG_DIR and an existing native session registration/socket.

  2. From a shell or Codex environment without that variable, run:

    session-peer list --agent claude --json --no-update-notice
    session-peer list --agent claude --all --json --no-update-notice
  3. The active profile-scoped Claude is absent.

  4. Query the actual profile explicitly:

    CLAUDE_CONFIG_DIR="$HOME/Library/Application Support/orca/claude-profiles/<profile-id>/home" \
      session-peer list --agent claude --json --no-update-notice
  5. The target appears. This temporary environment override is a discovery workaround, not permission to send or a delivery test.

Proposed bounded fix and acceptance criteria

  • Preserve existing explicit environment-root precedence and scope. An explicit CLAUDE_CONFIG_DIR / ANTHROPIC_CONFIG_DIR must not silently broaden into other accounts.
  • Without an explicit root, inventory the default root and known same-user Orca Claude profile roots. Bound enumeration and metadata reads; do not recursively scan arbitrary directories or follow unsafe entries.
  • Preserve bounded regular-file/PID/process-liveness/native-socket checks. Do not list arbitrary live processes as deliverable Claude sessions merely because Orca exposes a terminal.
  • Retain enough internal source/profile provenance for list, doctor, send/dry-run and existing generation checks to resolve the same record and native endpoint. Use additive public metadata only if needed; preserve ordinary output/exit compatibility and avoid exposing unnecessary paths or identity material.
  • De-duplicate the same native PID/inbox across aliases. Distinct records with conflicting ownership/identity must remain ambiguous/refused rather than selecting a profile by scan order. Duplicate names across distinct live sessions must not silently retarget.
  • Preserve healthy results when a different profile is missing, malformed or unreadable, while surfacing partial discovery errors instead of reporting a misleading fully successful empty result.
  • Read session registration metadata only. Never inspect/copy account authentication files, native *.key inbox credentials or transcripts; never connect to an inbox, send input, wake, restart, modify settings or relax ownership/generation checks during discovery.
  • Add offline fixtures for explicit-root scope, default plus multiple profiles, missing profile directories, malformed/unreadable/oversized records, stale PID/socket, duplicate PID/inbox and name ambiguity, alias/replacement races and partial failures.
  • Confirm the fix on an owned Orca profile using metadata-only discovery. No native send/model experiment is implied; any delivery acceptance requires separate authorization. Document both the workaround and supported inventory boundary.

Related: #30 documents the existing explicit configuration-root behavior (closed; not this automatic inventory gap). Preserve the Claude original-home/process/inbox binding from merged #286 / open #180; do not turn this into a prerequisite to implement native Codex generation or general ACK support.

Scope

Issue registration/triage only. No source change, PR, global upgrade, operational deployment or new native delivery test has been performed or requested by this issue.

Activity

  1. added
    bugSomething isn't working
    priority:P2Planned reliability, acceptance or feature work; priority does not authorize implementation.
    on Oct 19, 2026
  2. added this to the v1.2.1 milestone on Oct 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingpriority:P2Planned reliability, acceptance or feature work; priority does not authorize implementation.

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions