What Fervio asks for
Signing in takes you to GitHub's consent screen. Fervio is a GitHub App, so the permissions it can ever use are fixed on the app itself and listed publicly. You can read them before you grant anything. This page spells out each one and why it is there. Last updated 26 September 2026.
What GitHub will not let Fervio do
Fervio asks for five things: read and write access to issues, read access to repository names, read access to the member list when you use it with an organization, read access to the organization's issue field definitions so the roadmap knows which fields hold start and target dates, and read access to your email address so Fervio can reach you about your account. Access to file contents is not among them, and neither is access to pull requests.
You do not have to take Fervio's word for it. A GitHub App's permissions are declared on the app and enforced by GitHub, so a token issued to Fervio cannot reach your source code, even if Fervio tried. GitHub publishes the list, and you can read it without signing in to anything.
You also choose which repositories are in scope. Installing Fervio lets you pick specific repositories instead of all of them. The ones you leave out are invisible to Fervio, and GitHub enforces that too.
Every permission, and why
| Permission | Level | Why it is there |
|---|---|---|
| Issues | Read and write | The cards on the map are issues. Journeys, steps and estimates are labels; release rows are milestones. All three live under this one permission |
| Metadata | Read | Repository names, so a card can show which repository it belongs to. GitHub requires this of every app |
| Members (organization) | Read | When you use Fervio with an organization, Fervio asks GitHub whether you are a member before listing that organization. Fervio keeps no copy of that member list. On a personal account this is never used |
| Issue fields (organization) | Read | To find which of your organization's issue fields are Start date and Target date, so the roadmap can set dates on an issue that has none yet. Only the field definitions are read; the dates themselves are read and written under Issues. On a personal account this is never used |
| Email address | Read | To reach you about the account itself: a sign-in from a device you have not used before, billing, and changes to the terms or the service. You can change it or remove it in Settings |
| Contents (your code) | Not requested | Fervio never needs to open a file, so it never asks |
Email address. Fervio reads your verified address only, and keeps one address. You can change it to any address you prefer, or remove it, in Settings. Product news is a separate switch that is off until you turn it on.
How you sign in, and what you grant
| How you sign in | What you grant | What it can reach |
|---|---|---|
| Install on your own account | The same five permissions, on the repositories you select. The two organization ones go unused | Only the repositories you selected |
| Install on an organization | The same five permissions. An organization owner installs it | Only the repositories the owner selected |
| Viewing a shared link | No sign-in at all | The shared snapshot |
There is no wider version and no narrower one. Every sign-in path gets the same five permissions; only the repository list differs.
What it reads on GitHub
| When you | It reads | Needs |
|---|---|---|
| Create a board | The names of the repositories you selected, and how many open issues each has | Metadata |
| Open a map | The issues in those repositories, and the title, state, assignee, labels and milestone of each, and which issues each one waits on | Issues |
| Open the roadmap | On organization repositories, each issue's Start date and Target date, and the names of the organization's issue fields | Issues, Issue fields |
| Open a card | That issue's description, plus the assignees and labels you can pick from. One card at a time, fetched when you open it | Issues |
| See release rows | The milestones in those repositories | Issues |
Repositories you did not select are not read, and cannot be. The token cannot reach them.
What it writes on GitHub
Nothing is written unless you act in the app. An AI client you connect can only leave a proposal; it is written when you apply it in the app, as the same writes listed below. Opening a map, or leaving it open, writes nothing. There is no background job.
| When you | It writes | Needs |
|---|---|---|
| Add a journey or a step | Creates one label, named so that it cannot collide with yours. A step's label records its journey in the label description | Issues |
| Move a step to another journey | Rewrites the description of that step's label, which records its journey, in every repository the board reads | Issues |
| Rename a journey or a step | Renames that label in every repository the board reads. Renaming a journey also rewrites the description of the step labels under it | Issues |
| Delete a journey or a step | Deletes that label from every repository the board reads. The issues stay | Issues |
| Add a release row | Creates one milestone in the repository new issues go to | Issues |
| Link or unlink cards | Adds or removes a blocked by relationship between two issues | Issues |
| Change a card's dates, or drag its bar on the roadmap | Sets or clears that issue's Start date and Target date. Organization repositories only | Issues |
| Move a card to another repository | Transfers that issue to another repository the board reads | Issues |
| Move a card across columns | Swaps the journey and step labels on that issue | Issues |
| Move a card to another release row | Changes the milestone on that issue | Issues |
| Create a card | Creates one issue, with its journey and step labels | Issues |
| Change a card's state | Closes or reopens that issue | Issues |
| Change the assignee | Replaces who the issue is assigned to | Issues |
| Change the estimate | Swaps the estimate label on that issue | Issues |
| Add or remove labels | Replaces the labels on that issue. The ones holding the map together are kept | Issues |
| Edit the description | Overwrites that issue's body | Issues |
| Delete a card's issue | Deletes that issue after you press a second time to confirm. It cannot be undone on GitHub either | Issues |
| Move a card into a release row its repository does not have yet | Creates a milestone with the same title, description and due date in that repository. Only on boards that read more than one repository | Issues |
| Apply a map the AI panel drafted | Creates the journey and step labels it names, and one issue for each story, in the repository new issues go to | Issues |
Milestones are yours. Fervio reads them and moves issues between them, and never deletes one. Release rows come from your milestones on GitHub. It creates a milestone in two cases only: when you add a release row, and in the last row of the table above. A board that reads several repositories shows one release row per title, so moving an issue into a row its own repository lacks means creating that milestone there.
Signing in with Linear
Linear asks for read, write and
issues:create. Linear has no repositories and no source code,
so there is no “your code” line to worry about here. The scope names mean
what they say. Fervio reads teams, projects, issues, cycles and labels, and writes
issues and the projects, initiatives and labels that hold the map together.
What it reads on Linear
| To do this | It reads | Scope |
|---|---|---|
| Create a board | The names of the teams you belong to | read |
| Open a map | The team's projects, issues, cycles and labels, and each issue's title, state, assignee, estimate, due date, labels and sub-task progress | read |
| Show the journey bands | Initiative names, and the projects under them | read |
| Open a card | That issue's description. One card at a time, fetched when you open it | read |
What it writes on Linear
| When you | It writes | Scope |
|---|---|---|
| Move a card to another column | Changes the project that issue belongs to | write |
| Move a card to another sprint | Changes that issue's cycle | write |
| Move a card to another release row | Swaps the release label on that issue | write |
| Edit the description | Overwrites that issue's description | write |
| Create a card | Creates one issue | issues:create |
| Archive a card's issue | Archives that issue. It can be restored in Linear | write |
| Add a step | Creates one project, and links it to the initiative of the journey it goes under | write |
| Add a journey | Creates one initiative | write |
| Move a step to another journey | Links that project to the new journey's initiative, then removes its link to the old one | write |
| Add a release row | Creates one label that belongs to Fervio. The first release row on a board also creates the label group that holds them | write |
| Link or unlink cards | Adds or removes a blocks relation between two issues | write |
Changing a state, assignee, estimate or labels from the card panel works on GitHub only, for now. On Linear the card panel edits the description.
Nothing outside these two tables is ever written.
What it never touches
| Subject | Treatment |
|---|---|
| Source code | Cannot be read. The permission is not on the app, so no token Fervio holds can reach a file |
| Pull requests | Not requested. The permission is not on the app, so pull requests and their diffs are out of reach too |
| Repository settings, webhooks, Actions | Never touched. Those permissions are not on the app either |
| Repositories you did not select | Invisible. GitHub enforces this by scoping the token to your selection |
Narrowing it further
The permissions are already as narrow as the product can work with, so what you control is which repositories to select. Pick one to start with, and add more later from GitHub's own settings. Fervio does not need to be told.
Private repositories are not treated differently from public ones. Selecting a private repository grants issue access to that repository and nothing more.
If you are still uneasy
- Revoke at any time. Under Settings → Applications on GitHub, revoking Fervio's access stops it reading or writing anything from that moment on. Your map layout stays on Fervio's side, but nothing on GitHub is touched.
- Try it on a throwaway account. A second GitHub account with one repository and a few issues in it is the safest way to see what this does.
Organization repositories
An organization owner installs Fervio on the organization and chooses which repositories are in scope. The permissions are the same five. There is no extra one for organizations.
Members do not install anything. Each person signs in with their own GitHub account, and sees exactly the issues GitHub already lets them see.
When this changes
If Fervio ever asks for more, this page changes first. The privacy page lists what is stored, item by item. Questions go to [email protected].