Can Claude Code Auto-Load Context From an Assigned GitHub Issue?

No. Assigning a GitHub issue, to @claude or to anyone else, doesn't start anything in Claude Code. Nothing watches the assignee field. If you want a Claude Code session working on that issue, you either open claude.ai/code and create a task yourself, run claude --cloud "fix the bug in issue #482" from a terminal, or set up a GitHub Actions workflow that responds to an @claude mention in a comment. Assignment alone triggers none of it.

This isn't a configuration you're missing. Someone filed exactly this as a feature request in early 2026, describing the identical workflow you're probably picturing. Assign an issue, and a Claude Code Web UI session spins up automatically with the issue's title, description, and comments already loaded, then a PR comes back with Fixes #482 attached. Anthropic closed it as not planned. The manual copy-paste step it complained about is still there.

What actually gets a session to open

Two mechanisms exist today, and neither one is "assignment."

GitHub Actions with an @claude mention. The Claude Code GitHub Action runs in interactive mode when you mention @claude in an issue comment, a PR comment, a PR review, or the body or title of a newly opened issue. Anthropic's own phrasing is specific about that list, and assignment isn't on it. Mention the trigger phrase and Claude reads the surrounding issue or PR through the GitHub API and responds in a comment on the same thread. That's a real session with real issue context, but a human still has to type @claude to start it.

Routines with a GitHub trigger. Claude Code's routines feature can fire a session automatically off a GitHub webhook, no mention required. Routine GitHub triggers currently support two event categories, pull request (opened, closed, assigned, labeled, synchronized) and release, and issue events aren't one of them. A PR can trigger a routine the moment it's assigned. An issue, the thing the original feature request was actually about, cannot.

The DIY workaround, and what it actually gets you

You can close part of this gap yourself. Nothing stops you from writing a workflow file that triggers on issues: types: [assigned] and runs the Claude Code GitHub Action in automation mode with a prompt referencing ${{ github.event.issue.body }}. That's a legitimate pattern the docs already show for other triggers, like the scheduled-report example that runs on a cron and reads commits and issues through the GitHub API. Point the same mechanism at an assignment event and you get a session that starts the moment someone assigns the issue, with the issue body available to read.

What you don't get is the interactive Web UI session at claude.ai/code that you can steer, follow on your phone, and iterate with. Automation mode posts to the workflow run log or comments on the issue; it isn't the browsable session claude.ai/code gives you when you start a task by hand. And either way, the context you're loading is still bounded by the issue body and comments. It doesn't include the Slack thread where a customer first mentioned the bug, the Zendesk ticket with the repro steps, or which paying account is attached to it. That context lives in other tools, and a GitHub webhook can't reach across to them.

Dev Kapoor's Tuesday morning

At Runlevel, a twelve-person startup building workflow orchestration software for data teams, backend engineer Dev Kapoor had @claude wired up in the main repo. For a few weeks it worked the way the docs describe. Mention it in a comment, and a PR comes back.

On a Tuesday, Dev assigned himself an issue filed over the weekend, a data-pipeline retry bug, expecting the assignment to be the trigger the way it is on his team's internal Linear board, where assigning a ticket to someone puts it in their queue automatically. Nothing happened. No comment, no session, no PR.

Dev, in Runlevel's engineering channel: did assigning #214 to myself just... not do anything? thought @claude would pick it up

Teammate: yeah it only responds to the mention, assigning doesn't trigger it. you have to comment @claude on the issue itself

Dev commented @claude fix the retry bug described above on the issue, and a session started within a minute, reading the issue body and the two comments underneath it. It worked, but the retry bug had already come up in a Zendesk ticket from a customer three weeks earlier, phrased in different words, and neither Dev nor Claude Code had any way to know that from inside the GitHub issue alone.

When the gap stops being about triggers and starts being about context

Wiring up the assignment trigger yourself solves "how does a session start." It doesn't solve "what does the session know," and that second problem is the one that keeps costing time once the first one's fixed. An issue body tells Claude Code what got typed into GitHub, nothing more.

That's the layer Modem sits at. Modem watches your connected GitHub repos alongside Slack, Zendesk, Intercom, and the rest of your feedback surfaces, and keeps every bug report and request linked to the person and account behind it in a shared context graph. The Claude Code integration composes task descriptions from that graph, bug reports, user quotes, and topic data included, so a session Modem hands to Claude Code opens already knowing who asked and where, not just what the issue body says.

Reach the same data directly over Modem's MCP server (claude mcp add --transport http modem https://mcp.modem.dev/mcp), and Claude Code can query it mid-session instead of working from the issue text alone. We build Modem, so weigh that against your own setup. For a small team where one engineer reliably remembers the Zendesk ticket that matches a new issue, the manual @claude mention is genuinely fine. Past that, the join stops happening reliably, the same pattern covered in our guide on whether Claude Code can prioritize issues by customer impact and in triaging GitHub issues at scale.

Where this leaves you

Claude Code doesn't watch the assignee field on a GitHub issue, on the web or through GitHub Actions, and Anthropic has said that's not changing. What it does watch is an @claude mention, or a routine's GitHub trigger, which today covers pull requests and releases but not issues. You can build your own assignment-triggered workflow with the pieces Anthropic already ships, and it'll start a session, but it inherits the same limit every native option has. It only knows what's written in the issue. Whether that's enough depends entirely on whether the issue text is the whole story or just where the story happened to get typed down first.