Connect Mistral Work to GitHub: Permissions and First Read-Only Check

A green “Connected” badge is not enough to prove that a GitHub connection is correctly scoped. Before you let Mistral Work act on a repository, check three separate controls: which repositories and permissions the GitHub App receives, which Connector tools Mistral exposes, and which sensitive actions still require your approval.

This guide covers the current Vibe Work experience, usually labeled Work in the product. You will connect GitHub, verify the effective scope, and run a first task that only reads repository information. Navigation labels were checked against official documentation on September 30, 2026; the exact screens can still vary by account, plan, organization policy, or later UI changes.

Treat the connection as three permission layers

Layer	What it controls	Typical owner	Where to inspect it
GitHub App installation and authorization	Requested repository, organization, and account permissions; repositories the app can reach	Personal account owner, repository admin, or organization owner	GitHub installation screen and Installed / Authorized GitHub Apps
Mistral organization and workspace policy	Whether the Connector is available and which tools the model may call	Mistral organization or workspace admin	Admin Panel → Administration → Connectors
Per-function and per-action approval	Whether a particular read or write function can run without stopping	The current user, inside the admin perimeter	My Connectors → Functions and approval prompts during a task

These layers do not replace one another. A GitHub installation can include a repository while the Mistral workspace blocks the Connector. An admin can expose the Connector while Work still pauses before a write action.

Choose a personal connection or an organization-level connection

Use a personal connection when only your Work sessions need access. Mistral’s Work Connectors documentation directs users to open Connectors from the sidebar, select the GitHub App card, click Connect, and complete authentication. The credential belongs to the user, while access to organization repositories still depends on GitHub’s installation and organization policies.

Use an organization-level connection for a shared bot, a team workflow, or centrally governed access. An admin opens Admin Panel → Administration → Connectors, then uses App Connections to connect GitHub. According to Mistral’s admin Connector documentation, members can then use the connected app through Mistral without signing in individually. The admin can set the Connector in each workspace to:

• Allowed: all exposed tools are available in that workspace;
• Restricted: only selected tools are available;
• Blocked: the Connector is disabled for that workspace.

Start with a personal connection when the task is yours alone. In a managed GitHub organization or a shared automation, ask the organization and workspace owners to define the connection model and minimum tool set first.

Step 1: Start the GitHub connection from Work

1. Open Vibe and select Work; do not follow the separate Code or Studio Connector flow.
2. Open Connectors from the sidebar.
3. Find GitHub App and click Connect.
4. Complete the GitHub installation or authorization flow. GitHub may show an app installation, a user authorization, or both; they are different grants.
5. Return to Mistral and look for the green Connected indicator.

The badge confirms that authentication completed. It does not prove that the right account, repositories, or functions were selected, so do not begin with a repository-changing task.

Step 2: Review the current GitHub permissions and repository scope

GitHub’s third-party GitHub App installation guide says that the installation screen shows the repository and organization permissions requested by the app. When repository permissions are involved, you also choose All repositories or Only select repositories.

Review the screen in this order:

1. Installation owner. Confirm whether you selected your personal account or the intended organization. Installing on your personal account does not automatically grant access to repositories owned by an organization.
2. Permissions shown now. Read every requested permission on the current screen. Do not rely on a static list in an article: app permissions can change, and GitHub’s live installation or authorization screen is the source of truth for this grant.
3. Repository scope. Prefer Only select repositories when the task needs one or a few repositories. Use All repositories only when that wider current-and-future scope is genuinely required.
4. Installation versus authorization. Installation grants access to organization and repository resources and sets repository scope. Authorization can grant account-level access and let the app act on your behalf. GitHub may require either or both.
5. Unexpected write access. Stop before approving a write permission you cannot connect to the intended task. Mistral does not publish one timeless, universal permission inventory for every GitHub App installation, so this guide deliberately does not claim an exact fixed scope.

After installation, you can review it again. For a personal account, open Settings → Applications → Installed GitHub Apps → Configure. For an organization, open the organization’s Settings → Third-party Access → GitHub Apps → Configure. GitHub’s review and modification guide explains how to inspect permissions, change repository access, suspend the app, or uninstall it.

If GitHub shows Request instead of Install

Seeing Request or Install and request is often an organization policy outcome, not a broken integration. Organization owners can restrict GitHub App installation and can control who may submit access requests.

GitHub’s organization-owner request guide says that a member who cannot install the app can send a request to an owner. The owner may change the selected repositories before approving or rejecting it. Until that approval is complete, do not assume that a completed Mistral sign-in gives Work access to the organization repository.

Step 3: Limit the Connector functions available in Mistral

GitHub App permissions are the external boundary. Mistral’s Connector settings form a second boundary and need their own review.

For a user connection, open Connectors → My Connectors → GitHub App → Functions. Mistral’s Safety and approvals documentation divides functions into:

• Read-only tools, which get, list, or search information;
• Interactive tools, which create, update, delete, send, or post data.

For the first run, consider pre-authorizing only the read, list, and search functions you need. Keep functions that can create issues, post comments, change branches, or manage pull requests on manual approval. A per-function Always allow choice applies to the individual user; it does not grant the same permission to teammates. Use Refresh tools after a Connector update to reload the current function list.

For an admin-managed connection, use Restricted in the Admin Permissions tab and select only the tools required by that workspace. A team that only needs to read a README does not need every available write function.

Step 4: Run a first task that cannot intentionally write

Choose a repository whose output you can verify manually and that does not expose sensitive information. Enable the GitHub Connector for the task, then use a prompt such as:

Read only from the connected GitHub repository. Identify the default branch, list the files at the repository root, and summarize README.md in no more than five points. Use only read, list, or search functions. Do not create, edit, delete, comment, open or merge a pull request, or change repository settings. Stop and ask me before any action that could write to GitHub.

Do not judge the test only by the final prose. Expand the tool calls shown by Work and verify that:

• it used the GitHub Connector rather than web search or another source;
• the repository owner and name are correct;
• the selected function is read-only;
• the default branch, root files, and README details match GitHub.

If Work asks to approve a write action, choose Decline, inspect the proposed function, and narrow the task or tool set. Mistral currently presents Continue, Always allow, and Decline for sensitive actions. Avoid Always allow for write functions during an initial connection test.

What a successful first check looks like

A useful read-only check meets all of these conditions:

1. The Connector card shows Connected.
2. Work can reach an explicitly authorized repository and cannot reach an unselected private repository.
3. The visible tool call names the intended repository and a read-only function.
4. The result matches the source repository when checked manually.
5. No issue, comment, branch, pull request, file, or setting was created or changed.
6. For an organization repository, both the GitHub approval and the Mistral workspace policy are complete.

“The assistant answered a repository question” is not sufficient evidence. It may have used a public web page, old context, or the wrong repository. The tool call and source content matter more than a fluent answer.

Troubleshoot the layer that matches the symptom

Symptom	Check first	Action
GitHub only offers Request	GitHub organization installation policy	Wait for the owner; verify the requested repository list after approval
Mistral says Connected, but a private repository is missing	GitHub installation owner and Repository access	Open Configure, confirm the correct owner, and add the repository under Only select repositories
GitHub or a needed tool is absent in Work	Mistral organization/workspace policy	Confirm the active Organization and Workspace; ask an admin to review Allowed, Restricted, or Blocked
The function list is outdated	Connector tool list or admin restriction	Use Refresh tools, then compare with the Admin-selected tools
A read-only task triggers a write approval	Prompt scope or enabled function is too broad	Select Decline, inspect the function, narrow the prompt, and disable unnecessary interactive tools
Repository scope changed but Work still shows old behavior	GitHub and Mistral state differ	Confirm GitHub saved the change, refresh tools or reopen the connection; reconnect only if the current UI still shows stale access
You stopped using the integration	Installation and authorization may both remain	Suspend or uninstall the Installed GitHub App and review Authorized GitHub Apps for a separate user authorization

Review access periodically and remove it when the task ends

Repository sensitivity, team membership, and app permissions change. Recheck the integration when a project ends, someone leaves the team, a repository becomes sensitive, the app requests additional permissions, or you stop using Mistral Work.

On GitHub, review the current permissions and repository list. In Mistral, review the workspace Connector state, admin-selected tools, and any functions you personally marked Always allow. When access is no longer needed, disconnect it in Mistral and then suspend, uninstall, or de-authorize the GitHub App as appropriate.

Start by proving read access, then add write capabilities deliberately

The safest minimum path is not “connect and let the agent edit the repository.” It is: choose the correct personal or organization connection, read the live GitHub grant, narrow the repository scope, limit Connector tools, and complete a manually verifiable read-only task.

Only after those checks pass—and after your team has agreed on the approval policy—should you enable interactive functions for issues, comments, or pull requests one by one. That process remains useful even when account options or UI labels change, because it follows the three actual permission boundaries.

Official references

• Mistral: Connect tools with Connectors
• Mistral: Safety and approvals
• Mistral Admin: Connectors
• GitHub: Installing a GitHub App from a third party
• GitHub: Reviewing and modifying installed GitHub Apps
• GitHub: Requesting a GitHub App from an organization owner