Run Claude Code on your Linear issues, in the cloud, with Buildful

Buildful runs Claude Code on your Linear issues in a cloud sandbox. You don't install anything, and nothing runs on your laptop. You add a label to an issue, and the issue gets a pull request attached, with your checks run. When the change touches the UI, it also gets a QA testing recording: a video of the agent testing the feature in a real browser. On the three issues I tried, the pull request came back in 3 to 4 minutes.

Getting a pull request out of an issue is the easy part now. Knowing it works before you merge is the hard part, and that's what the QA recording is for.

It works in four steps:

1. Connect Linear to Buildful and choose a label and an agent. You do this once.
2. Write an issue the agent can finish.
3. Add the label to the issue. Buildful picks it up, builds it and runs your checks. If the change touches the UI, it tests it in a browser and records the test.
4. Review the pull request and merge. You can do this from your phone.

I co-founded Hashnode and Bug0, which tests web apps with AI, and I'm building Buildful with Sandeep Panda. So weigh the product parts with that in mind. Everything below comes from three real issues on QuietMD, a markdown editor I build on the side.

The dark mode issue in Linear after the handoff. I added one label, and Buildful attached the pull request when it was done ("Created automatically by Buildful"). Here's how to set that up.

Step 1: Connect Linear to Buildful

It takes a few minutes, and it works on any Linear plan you can install it on.

1. In Buildful, open Integrations and click Connect on the Linear card.

   

2. Authorize Buildful in Linear. When you come back, the card says "Connected" and shows four fields.

   

3. Fill in the fields. Mine:

   • Linear team: QuietMD.
   • Trigger labels: buildful-handoff. Type it and press Enter. I made a label that exists only for this, so nothing starts by accident.
   • Repository for new tasks: fazlerocks/quietmd, a private repo.
   • Coding agent: Claude Code (Opus 5.5). The next section covers this choice.

   

4. Click Enable automation. The card switches to "Configured", and a message confirms "Linear automation is active".

   

5. Tell Buildful how to check your code. On the Repos page, open the repo's settings and add its setup and check commands. For QuietMD that's npm ci to install, then npm run lint, npm run typecheck and npm run build, the same checks its CI runs. Every pull request gets checked against these.

Step 2: Choose Claude Code or Smart Mode

Whichever agent you pick, the work runs the same way: in Buildful's sandbox, with your checks, and QA testing in a real browser for UI changes.

• Claude Code is on the Pro and Team plans. You can pick Opus 5.5, Sonnet 5.5 or Fable 5.1, and we add new frontier models from the major vendors as they come out. Pay from credit you top up in advance in Buildful (from $5), or bring your own key (BYOK): add your Anthropic API key and usage is billed to your Anthropic account. I used BYOK.
• Smart Mode is the default on every plan. Buildful picks the right open-weight model for each task. On Pro that's 1,000 tasks for $10 a month, about a cent a task. Team is $40 a month for 3,000 tasks, and Buildful pricing has the details.

Codex and Grok Build are in the same list. To switch agents later, pick another one in the Coding agent field and click Update automation.

Every agent you can hand Linear issues to, in one list. Here I'm switching to Smart Mode for the third issue.

Step 3: Write an issue the agent can finish

Agents fail on vague issues more than on hard ones.

"Add dark mode" leaves every decision to the agent: should it add a button, should it remember the choice, where are the colors? Here's the issue I wrote instead:

Add dark mode with a keyboard shortcut

QuietMD has dark theme colors in globals.css (the .dark class), but nothing turns them on. Add dark mode.

• On a first visit, follow the system's light or dark setting.
• A keyboard shortcut switches between light and dark. Pick one that doesn't clash with common browser shortcuts.
• Remember the choice after a reload.
• Don't add a visible button. CONTRIBUTING.md asks for shortcuts over new controls. Mention the shortcut in the README's Features section and remove "No dark mode toggle" from Known limitations.

It says what I want, where the existing work is, and the rules the result has to follow. That's enough for an agent to finish it without guessing. One issue should lead to one pull request.

Step 4: Add the label

Adding the label is the whole handoff. The dark mode issue went from label to pull request in 4 minutes.

1. I added buildful-handoff to QUI-1 in Linear.

2. A task started in Buildful with the issue's text and a link back to it. It set up a sandbox, cloned fazlerocks/quietmd and started Claude Code (Opus 5.5). I could follow every step live.

   

   The task page in Buildful: the issue as the task, then each step as it happens.

3. Before writing code, it read the docs bundled with the repo's version of Next.js, as QuietMD's AGENTS.md asks, and used the approach they recommend so the page never flashes the wrong theme.

4. It wrote the feature, ran the checks, then re-read its own diff and caught a bug before testing: the shortcut's label would have broken the shortcut table on QuietMD's welcome page. It fixed it.

5. It QA tested dark mode in a real browser and recorded a 47-second video: switching themes with the shortcut, reloading to check the choice stuck, and opening Preview in dark mode.

   

   The end of the task: the QA recording, the pull request, and a command to preview the branch without any local setup.

6. It opened pull request #2 and attached it to the issue in Linear.

It reused the existing .dark colors and added no button. For the shortcut it picked ⌘\ (Ctrl+\ on Windows and Linux), after ruling out ⌘⇧L, which Safari uses for its sidebar, and ⌘⇧D, which bookmarks all tabs in Chrome and Firefox. It also updated the README, including the new Features entry and where the choice is saved.

Step 5: Review and merge, even from your phone

When the proof is in the pull request, you can review it anywhere.

The pull request's description has a summary of the work, a self-review of the code, the steps it verified, its caveats, the QA testing recording, and the original task. Our first post explains what goes into each part and the rules for the browser test. The caveats are worth reading. Mine said it tested only in Chromium, not in real Safari or Firefox, on a real Mac, or at phone widths. That's exactly what I want to know before I merge.

Watch the QA recording from the dark mode pull request (47 seconds).

I check three things before I merge:

• Did the checks run and pass? They're listed in the pull request. If one still fails, it says which.
• Is there proof it works? For a UI change, the QA recording shows the feature working, which beats a paragraph saying it works.
• Did it stay in scope? The changes should match what the issue asked for.

On GitHub, the pull request shows a short GIF of the QA test, and the full recording opens in Buildful after you sign in. Both work on your phone, and so does merging in the GitHub app, so you don't have to open your laptop. If you want to read every line, it's a normal pull request on GitHub.

My three runs

All three issues went from label to pull request in three to four minutes.

Besides dark mode, I handed off two more issues the same way: a bug fix with Claude Code, and a small feature with Smart Mode. For the third one, I switched the Coding agent to Smart Mode before adding the label.

All three issues in Linear, each handed off with the same buildful-handoff label.

Claude Code started the Tab bug by reproducing it before changing anything, and opened pull request #1 three minutes later. In the QA recording, Tab nests a list item, Shift+Tab takes it back out, and Ctrl+Z restores the indent, so undo still works. Its caveats flagged a trade-off I hadn't thought about: with Tab captured, you can no longer press Tab to move focus out of the editor.

The Tab bug with Claude Code: it reproduced the bug first.

Smart Mode explored the repo before it wrote anything, five files and one search, then made the change in the editor component and opened pull request #3 in four minutes. In its QA recording, it typed paragraphs with a code block, inline code, a link and emphasis, and the footer read "23 words · 1 min read", the same as a count it worked out separately, so code and markdown symbols weren't counted. Its caveats noted the one gap: code indented with four spaces still counts.

The word count with Smart Mode: it read the repo before writing code.

They're different issues, so read this as three examples, not a contest between agents.

What it can't do yet

• One Linear team and one repository per setup.
• Only the pull request link goes back to Linear. There's no progress update on the issue while it runs.
• Each issue starts one task. Once a task is created, adding the label again doesn't start another, even if that task failed, so retry it in Buildful. If Buildful couldn't start the task, for example because you were out of tasks, you can add the label again.
• The browser test and its recording happen only when the change touches the UI.
• Follow-up requests happen in Buildful, not in Linear comments.

Other ways to put a coding agent on Linear issues

If Buildful doesn't fit, these are the other routes.

• Claude Code on your own machine. Connect Linear's MCP server, and Claude Code can read your issues while you work:

  claude mcp add --transport http linear-server https://mcp.linear.app/mcp
  

  Then run /mcp inside Claude Code to log in (Linear's MCP docs). It runs on your laptop, nothing goes back to Linear unless you ask for it, and nothing is tested unless you test it.

• Linear's own coding sessions. Linear's agent runs Claude Code or Codex in the cloud and returns a draft pull request that it has tested. It needs a paid Linear plan and AI credits (Linear's docs).

• Assign the issue to another agent inside Linear. Copilot opens a draft pull request. Cursor updates the issue with one. Codex posts a summary and a link for you to create the pull request. Devin syncs its plan to the issue and links its pull request.

Several of these can test their own work too. Buildful tests and records every UI change by default, on every task. With the others, how much gets tested, and whether you get a recording, depends on the tool and how you set it up. We compare Buildful with Claude Code, Cursor, GitHub Copilot and Codex on their own pages.

Frequently asked questions

How do I use Claude Code with Linear?

Two ways. In Buildful, set the Linear integration's coding agent to Claude Code, and labeled issues run in Buildful's cloud sandbox. Or connect Linear's MCP server to Claude Code on your own machine with claude mcp add --transport http linear-server https://mcp.linear.app/mcp, then log in with /mcp.

Does it work on Linear's Free plan?

Yes, as long as you can install the integration in your Linear workspace.

Is there a Claude agent inside Linear?

There's no Anthropic agent in Linear's agent list. Linear's own coding sessions can run Claude Code, and so can Buildful.

Will the Linear issue close when the pull request merges?

Yes, if you use Linear's GitHub integration. It moves the issue when the linked pull request merges.

To try it on your own Linear issues, start building on Buildful.