[FEATURE] shareable/linkable remote agent sessions scoped to work items

Open 💬 0 comments Opened Jun 16, 2026 by mhelgerson

Preflight Checklist

  • [x] I have searched existing requests and this feature hasn't been requested yet
  • [x] This is a single feature request (not multiple features)

Problem Statement

When working on a ticket or PR, all investigation, decision-making, and implementation happens inside a local Claude Code session — but that session context is ephemeral and private. When the PR goes up for review, the reviewer sees only the diff. They have no visibility into what was investigated and ruled out, what constraints were discovered, why a particular approach was chosen over alternatives, or what the AI reasoned through to get there. The full "why" lives in a session that disappears when the window closes.

This creates a two-tier knowledge gap: the author has rich context, the reviewer has almost none. Review quality suffers because reviewers are asked to evaluate decisions without the reasoning that produced them.

Proposed Solution

Cloud agents should be first-class, addressable, shareable objects — one per work item.

When starting work on a ticket, the engineer launches a named cloud agent:
claude agent start --name "JIRA-1234" --remote

All work for that ticket happens inside that agent — investigation, edits, commits, PR creation. The agent session gets a stable URL (e.g. claude.ai/agents/JIRA-1234 or similar). When the PR is created, that URL is embedded in the PR description automatically.

A reviewer clicks the link, opens the full live session, and sees the complete history: what files were read, what was considered and rejected, what the key decision points were, and why. The agent stays open so reviewers can ask follow-up questions directly inside the session context.

Alternative Solutions

Alternative Solutions

  • PR description summaries: we currently write manual summaries of AI reasoning into PR bodies, but these are lossy, written after the fact, and require the author to remember to do it.
  • Forking session context into comments: posting a structured "AI session context" comment to the PR via gh pr comment. Gets the reasoning into GitHub but is still a static snapshot, not the live session.
  • Session transcript files committed to the branch: writing a .claude/session-notes.md into the branch. Durable but noisy in the diff and not interactive.
  • Other tools: Linear and Notion have "AI threads" scoped to issues, but they're not connected to the actual implementation work in the terminal.

Priority

High - Significant impact on productivity

Feature Category

Other

Use Case Example

  1. Engineer picks up ticket JIRA-1234: "pact publish failing on Docker Hub rate limit"
  2. They run claude agent start --name JIRA-1234 --remote — a named cloud agent session opens
  3. All investigation happens inside: fetching the failing CI run, grepping org repos for the auth pattern, reading the reusable workflow, applying the fix, pushing the branch, creating the PR
  4. PR #155 is created — the agent URL is automatically appended to the PR description
  5. Reviewer opens the PR, clicks the session link, and sees: the exact CI error that was investigated, the 4 org repos that were checked for the auth pattern, the decision to use docker/login-action v3 pinned by SHA, and the reasoning for why no caller-side changes were needed
  6. Reviewer can ask "why not fix this in the caller repos instead?" directly in the session and get a grounded answer from the agent that already has full context loaded
  7. Session is archived with the PR — six months later, anyone asking "why does this workflow have a Docker login step?" can trace it back

Additional Context

This mirrors how some teams use Loom or detailed commit messages to preserve decision context — but those are manually authored and separate from the actual work. A per-work-item cloud agent session makes the context automatic and interactive, not a documentation burden layered on top of engineering work. The session IS the artifact.

View original on GitHub ↗