Most developer tools treat task tracking and actual work as two separate systems, connected by, at best, a link: a GitHub issue that opens a browser tab, a Linear ticket that opens another, a terminal that has no idea either one exists until you copy the acceptance criteria into it by hand. Influxx treats a GitHub pull request or a Linear issue as something better than a reference to read before the real work starts — a legitimate starting point for the work itself. See the task inside the cockpit, open a dedicated worktree for it in one action, and start reviewing the actual diff against the actual issue, with no browser tab in between.
A Link Is Not an Integration
The default way a task tracker and a coding tool relate to each other is a hyperlink. A pull request description links to the ticket it closes. A ticket links to the pull request that implements it. Click through enough of those links in one afternoon and you notice that the link is doing all the work an integration is supposed to do — it's just a pointer, and every click on it is a full context switch: a new window, a new page load, a new few seconds of re-orienting yourself before you can even start reading.
We think that's the wrong unit of integration. A GitHub issue or a Linear ticket isn't only something to read before opening a terminal — it's the thing that should determine what the terminal gets pointed at. So instead of linking out to the task, Influxx brings the task in: pull requests and issues from GitHub, and project boards and issues from Linear, are browsable inside the cockpit as real working views, not an embedded copy of a page you'd otherwise load somewhere else.
The Tab-Switching Tax
It's worth being specific about what this actually removes, because the friction rarely shows up as one dramatic moment. It shows up as a tax paid dozens of times a day, in increments too small to notice individually and too large to ignore in total. Consider one ordinary pass through a single task, the kind that happens on nearly every piece of work in progress:
- Checking whether the build is still green: a tab out to see the checks on a pull request, a tab back, just to confirm what you already suspected.
- Re-reading what the task actually asked for: a tab out to the original issue, because the acceptance criteria you skimmed an hour ago has already faded, and the terminal in front of you has no memory of it.
- Making the change itself: a tab back to the terminal, where the actual work happens, disconnected from both of the tools you just visited.
- Confirming a review comment landed: a tab out again, to check whether the fix you just made actually addresses what a reviewer flagged, before you push something that misses the point.
None of those four steps is hard by itself. What they cost is continuity — the thread of attention that has to be rebuilt every time a switch interrupts it. Multiply that by however many tasks move through an ordinary day, and the tax adds up to something real, even though no single instance of it looks like a problem worth fixing.
Not a Browser Tab, and Not a Widget Either
There's a cheap way to build this kind of integration and a real one, and it's easy to tell them apart once you've used both. The cheap version is a browser view docked inside the app so it feels included — same load times, same re-orientation cost, same feeling of having left, just wearing a different frame. The other cheap version is a read-only widget: a card showing an issue's title and its status, useful for a glance and useless for anything more, because the moment you need to actually do something with it, you're back to opening the real site in a real browser.
Influxx's GitHub and Linear support is neither. Pull requests and issues from GitHub, and boards and issues from Linear, render as real working views inside the cockpit — the same surface you'd use to actually read a discussion or triage a backlog, not a preview of one. That's the difference native GitHub and Linear integration is supposed to make: it determines what you can do next without leaving, not just what you can look at.
"We could have shipped a docked browser view and called it an integration — it would have demoed fine. But a docked browser view is still a browser view: same load times, same feeling of having left, just framed differently. We wanted opening a pull request in Influxx to feel like opening a file, not like leaving the app wearing a disguise."
— Sofia Reyes, Head of Product at ETAPX
From Issue to Isolated Worktree, One Action
The clearest payoff shows up at the exact moment a task turns into work. See an open pull request or a Linear issue inside Influxx, and one action opens a dedicated worktree for it — no prompt to clone the repository, no reminder to check out the right branch, no second trip to re-read the issue description because the terminal is finally ready and you've already forgotten the acceptance criteria. One action, and the result is an isolated environment with that specific piece of work already checked out.
That one action collapses three separate manual steps most developers do so often they stop noticing them as steps at all:
- Finding the right branch: normally a matter of copying a branch name out of a pull request page and pasting it into a terminal, or guessing at it when the name isn't obvious.
- Isolating the change: normally a matter of remembering whether your working copy already has uncommitted changes on it before you check out something new on top of them.
- Re-establishing context: normally a matter of leaving a second window open just so the issue description is still visible once you actually start working.
Influxx replaces all three with the one action a developer actually wants: here's a task, now here's an isolated environment with that task's code checked out, ready to review or ready to hand to an agent.
Reviewing the Diff Where the Task Already Lives
Once the worktree exists, review happens without a second window. The pull request's description, the Linear issue's acceptance criteria, and the diff an agent or a teammate produced are all visible in the same cockpit — the same one already holding the worktree and, if an agent is still involved, the same one running that agent's session. Reading a diff against the task it's supposed to satisfy stops requiring two monitors or a mental cache of what the ticket said an hour ago, because the ticket is one tab away, not one application away.
"I used to have a whole ritual before I could actually start reviewing an agent's pull request — clone if I hadn't already, check out the branch, open a second monitor with the Linear ticket so I wouldn't lose the acceptance criteria halfway through. Now I open the pull request inside Influxx and the worktree is just there, checked out, ready. The ritual is gone and I don't miss it."
— Leah Ferreira, senior engineer at a payments infrastructure company and Influxx user
Linear Gets Treated Like Linear, Not Like GitHub With a Different Skin
It would have been easy to build GitHub support first, get it right, and then port the same design onto Linear with new icons and call it finished. A lot of task-tracking integrations work exactly that way, and the tell is always the same: whatever concept doesn't map cleanly onto GitHub's model quietly disappears.
We didn't build it that way. Linear has its own vocabulary for organizing work — scoped views that filter a large, shared set of issues down to what's actually relevant to the project or team in front of you — and Influxx treats that vocabulary as worth preserving rather than flattening into a generic issue list. A busy Linear workspace can hold issues across dozens of teams and projects at once; a scoped view is how a Linear user already narrows that down to what matters right now, and Influxx honors the same scoping instead of asking you to re-filter a firehose from scratch.
"The lazy version of Linear support treats an issue as a GitHub issue with a different color. The moment you do that, everything Linear users already rely on to manage a large backlog — the scoped views they've already set up — stops meaning anything inside the tool. We didn't want the deeper GitHub integration to become the ceiling for what Linear support felt like."
— Daniel Kwon, Staff Engineer, Agent Orchestration at ETAPX
Closing an Issue Should Mean What You Meant
The same instinct shows up in a smaller, easier-to-miss detail: what happens when you close a GitHub issue from inside Influxx. GitHub's own interface doesn't treat "closed" as a single state — it asks whether an issue was completed, marked as not planned, or closed as a duplicate of another specific issue, because those are three different facts about why work stopped, and they read differently to whoever looks at that issue's history months later.
A closing action that only offers one generic closed button quietly throws that distinction away. Influxx doesn't. Closing an issue from inside the cockpit supports the same richer set of reasons GitHub itself offers, including linking a duplicate to the specific issue it duplicates, so the action you take from inside Influxx carries the same nuance it would have carried if you'd taken it directly on GitHub's own site. It's a small feature to describe and an easy one to get wrong by omission, which is exactly why we treated it as a requirement rather than a nice-to-have.
What Changes on an Ordinary Task
None of this is one dramatic feature. It's a dozen small removals of friction that used to be invisible because they were so routine. A task that used to require a browser tab to read, a second browser tab to check status, a terminal to actually work in, and a third browser tab to close out correctly now requires one surface: the cockpit already running the agent and holding the worktree. The work doesn't get easier because Influxx made the code smarter. It gets easier because the distance between reading a task and acting on it stopped being a distance at all.
Frequently Asked Questions
Isn't this just an embedded browser tab for GitHub and Linear?
No, and that distinction is the whole point. An embedded browser tab still carries a browser tab's friction — a full page load, a different set of interactions, the feeling of having left even when the frame around it says you haven't. Influxx renders GitHub pull requests and issues, and Linear boards and issues, as real working views inside the cockpit, built to let you open a worktree directly from what you're looking at, not a preview pane you eventually abandon for the real site.
What actually happens when I open a worktree from a pull request or a Linear issue?
One action takes you from "here's a task" to "here's an isolated environment with that task's code already checked out." There's no manual clone, no hunting for the right branch name, and no separate window kept open just so the issue description stays visible once you start working. The worktree that opens is scoped to that specific piece of work, the same isolation model Influxx uses for every worktree it creates.
Can I close a GitHub issue from inside Influxx with the same nuance as closing it on GitHub's own site?
Yes. Influxx supports GitHub's fuller set of closing reasons — completed, not planned, or duplicate of a specific other issue — instead of collapsing every closure into one generic "closed" state. The nuance you'd have closing it directly on GitHub is the nuance you get from inside the cockpit.
Does Linear support feel like an afterthought bolted onto GitHub, or does it get real first-class treatment?
First-class treatment was the specific goal. Linear-specific concepts — like the scoped views a team already relies on to filter a large set of issues down to what matters for a given project — are preserved as they are, rather than flattened into a generic issue list borrowed from GitHub's model.
Do I still need to keep a browser tab open just to track a task while I work?
For the ordinary loop — seeing a task, opening a worktree for it, and reviewing the diff against what the task actually asked for — no. That loop is exactly what native support keeps inside the cockpit, next to the worktree and whatever agent session is already running there.
Does this work for pull requests and issues I didn't open myself, or only my own?
It isn't scoped to only what you personally authored. A pull request or issue anywhere in a project you have access to opens into its own worktree the same way, which matters most on teams where the person reviewing a piece of work isn't the person who created the task for it.
None of this changes what a pull request or a Linear issue actually is — it's still a description of work someone needs done, and someone else's judgment about whether it's done right. What changes is where that judgment happens. Influxx treats a task as a legitimate place to start work from, not a reference to close out of before the real tool opens, and that one shift is what keeps a developer's attention in one place instead of scattered across four tabs and a terminal.
