---
title: Project view — Issues & PRs
description: Surface open issues and pull requests from the resolved SCM provider on the repo overview screen.
---

When you click a repo in the sidebar without selecting a workspace, Claudette renders a project overview screen. By default that view shows the "Start a workspace" card, active workspaces, and the archived list — what's outstanding *locally*.

Turn on **Show open issues & PRs in project view** to also surface what's outstanding *upstream*: open issues and open pull requests for that repo, pulled through the same SCM provider plugin (`scm-github`, `scm-gitlab`) that already powers Claudette's per-workspace PR badges.

## What you see

Between the "Start a workspace" card and the Workspaces section, two new collapsible sections appear:

- **Issues** — open issues with their label chips (max 2 visible per row, "+N" overflow), comment count, and relative age. Click a row to open the issue in your browser; right-click for Open / Copy URL.
- **Pull requests** — open PRs with a scope selector at the section header:
  - **Open** — every open PR on the repo
  - **Mine** — open PRs authored by you (`@me` via `gh` / `glab`)
  - **Review** — open PRs where review is requested from you

Each PR row shows the PR's number, a CI-tinted state icon (open / draft / merged / closed; the open variant tints by CI status), title, `base ← branch`, and author.

Right-click any issue or PR row for:

- **Open in browser** — opens the row's URL in your default browser.
- **Copy URL** — copies the URL to the clipboard.
- **New workspace in this repo** (PR rows only) — creates a workspace on the repo's default base branch (**not** the PR head) and surfaces the PR head branch in a toast.
- **Go to workspace “&lt;name&gt;”** — shown only when a workspace has already been sent this issue/PR. Jumps straight to that workspace. It sits *above* "Send to new workspace", not in place of it, so spinning up a second workspace on the same item stays one deliberate click away.
- **Send to new workspace ▶ &lt;model&gt;** — opens a submenu of available models. Pick one to (1) create a fresh workspace in the repo, (2) apply the chosen model to the new session so the toolbar reflects it and any cross-harness setup runs, and (3) auto-send a templated starter prompt as the first turn so the agent begins working immediately.

  The starter prompts link back to the source:

  - Issues: `Please investigate and address issue #<N>: <title>\n\nSource: <URL>`
  - Pull requests: `Please review PR #<N> and continue or refactor as needed: <title>\n\nSource: <URL>\nBranch: <branch>`

  The submenu lists the same models the chat panel's model picker would show, with the same alternative-backends and OAuth gating. If you have no models available (alt-backends off and no Claude auth), the submenu shows a single disabled "No models available" row instead of silently swallowing the click.

  You can pick models for several issue/PR rows in quick succession. Claudette queues the workspace creates so each distinct row still gets its own workspace and starter prompt, while an accidental repeat click on the same row is collapsed instead of creating a duplicate.

## Issue / PR ↔ workspace association

When you send an issue or PR to a workspace, Claudette records the link — which workspace was spun up for which upstream item — and surfaces it on both sides:

- **In the project view**, dispatched issues/PRs are lifted into a collapsible **"In progress"** group at the top of the list, above the plain **"Open"** group — so they stay visible even if they'd otherwise sit past the row cap. Each dispatched row also carries an accent-tinted **badge** with its workspace's name; click the badge (or the right-click **Go to workspace** item) to jump straight to it. No more sending the same issue to two workspaces by accident.
- **On the workspace**, the chat header breadcrumb gains a `#<N> — <title>` pill (click it to open the issue/PR in your browser), and the sidebar workspace row gains a small accent dot whose tooltip names the item. Both make it obvious what each workspace is for.

The link is keyed on the workspace — one workspace owns at most one item. It survives an **archive → restore** round-trip: archiving a workspace only hides its badge, it doesn't drop the link. Hard-deleting the workspace drops the link for good.

The association is part of this feature: with **Show open issues & PRs in project view** turned off, no links are written and none of the badges, breadcrumbs, or sidebar dots appear.

Both sections poll every 60 seconds while the project view is visible. Polling pauses on `visibilitychange` to hidden — Claudette doesn't burn your `gh` / `glab` rate-limit budget for a tab you walked away from. The Refresh button in each section header forces an immediate fresh fetch.

## How to enable

Open **Settings → Git → Project view** and flip **Show open issues & PRs in project view** on.

The toggle is off by default. Once enabled, the feature is doubly gated:

1. The flag itself (persisted as `project_view_issues_prs_enabled` in `app_settings`).
2. The repo must have a resolved SCM provider. If `git remote get-url origin` doesn't match any installed plugin's `remote_patterns`, the sections don't render — same gate today's sidebar PR badge uses. A repo with no remote, or a remote that no installed plugin claims, sees no change.

Both gates are checked backend-side too: with the flag off, the Tauri commands return empty without invoking the SCM plugin, so a stale frontend cannot trigger network calls.

## Supported providers

Bundled plugins:

- **`scm-github`** — wraps `gh issue list` and `gh pr list`. Available out of the box if you have the GitHub CLI installed and authenticated (`gh auth login`).
- **`scm-gitlab`** — wraps `glab issue list` and `glab mr list`. Available out of the box if you have the GitLab CLI installed and authenticated (`glab auth login`).

User-authored SCM plugins can implement `list_issues` to participate. Plugins that don't implement the operation degrade gracefully: the Issues section renders an "Issues are not supported by this provider" muted hint while the Pull requests section continues to work normally.

## Privacy

All data is fetched on your machine using the credentials in your own `gh` / `glab` CLI. Claudette does not phone home, does not store an OAuth token, and does not proxy through any third-party server.

A small SQLite cache (`repo_scm_lists_cache`) keeps the most recent response per `(repo_id, list_kind)` so the project view paints instantly on app launch instead of waiting for the first poll. Entries are anchored 60 seconds in the past on boot so the first visible visit always triggers a fresh fetch.

Issue/PR ↔ workspace associations live in a separate local table (`workspace_scm_links`) — just the item number, URL, and title alongside the workspace id. Like everything else here it never leaves your machine.

## Limits

- Default 10 visible rows; click **Show all (N)** to expand to 50. Beyond 50, use the provider's web UI.
- Sort: `updated_at DESC` (matches `gh` / `glab` defaults). No client-side resort.
- Avatars are not rendered in v1 to keep the GitHub rate-limit footprint flat. A separate setting may add them later behind a per-plugin URL allowlist.
- "New workspace in this repo" (PR row right-click) creates a workspace on the repo's default base branch and surfaces the PR head branch in a toast. Threading the PR branch through the create flow lands as a follow-up — see the issue tracker.

## Troubleshooting

- **The sections don't appear**: confirm the toggle is on AND that the repo's git remote matches an installed SCM plugin. The Settings → Plugins page shows which providers are loaded and which CLIs (`gh` / `glab`) are detected.
- **Rate-limit errors**: GitHub's anonymous rate limit is 60 req/hr; authenticated is 5000 req/hr. If you see persistent retry banners, `gh auth status` will confirm authentication; the polling cadence is 60 seconds so a single repo's footprint is tiny — most rate-limit pressure comes from other tooling on the same token.
- **"Issues are not supported by this provider"**: the resolved plugin doesn't declare `list_issues` in its `plugin.json` `operations` list. Open the plugin's manifest to add it, or use a provider that does (`scm-github`, `scm-gitlab`).
