Skip to content

Expose sidebar visibility in worktree list #701

Description

@adamgall

What problem does this solve?

Git registration and Supacode sidebar visibility are different states. supacode worktree list currently prints every worktree known to Supacode, including archived worktrees, while supacode worktree list -f only narrows that list to the focused worktree. Neither command identifies the default workspace, pinned worktrees, and unpinned worktrees as visible or archived worktrees as archived.

Scripts therefore have to read ~/.supacode/sidebar.json and depend on its private schema to reproduce what the app shows. Git cannot provide this state because pinning and archival belong to Supacode.

Proposed solution

Preserve the existing default output of one percent-encoded worktree ID per line, and add the smallest stable machine-readable interface needed to:

  • filter the list to sidebar-visible worktrees;
  • optionally emit each ID with a visible or archived classification when listing all worktrees;
  • report the repository's default workspace as visible;
  • preserve the existing percent-encoded IDs.

For example, worktree list --visible could keep the existing one-ID-per-line shape while filtering, and worktree list --with-visibility could emit tab-separated <id>\t<visible|archived> rows. The app's existing sidebar-state owner should provide the classification; the CLI should not parse sidebar.json or duplicate the UI rules.

Related, but not duplicates:

Alternatives considered

  • Parse ~/.supacode/sidebar.json: couples scripts to private storage and duplicates Supacode's classification rules.
  • Infer state from Git locks, tabs, branches, paths, or processes: none represents Supacode sidebar visibility.
  • Change the default worktree list rows: risks breaking scripts that consume one percent-encoded ID per line.

Supacode version

0.10.6

Are you planning to build this yourself?

  • I intend to open a pull request once this is approved and marked ready.

Before submitting

  • I searched existing issues and this is not a duplicate.
  • I understand feature pull requests are closed until the issue is marked ready.
  • I agree to follow this project's Code of Conduct.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestreadyApproved for a pull request. Added by a maintainer once an issue is triaged.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions