> For the complete documentation index, see [llms.txt](https://docs.datasentinel.io/manual/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.datasentinel.io/manual/ai-connector/connect-a-cli-assistant/configure-copilot-cli.md).

# Configure GitHub Copilot CLI

Connect the GitHub Copilot CLI to your Datasentinel MCP server on Linux, sign in, install the Datasentinel Skill, and verify the configuration.

This page shows how to wire the [GitHub Copilot CLI](https://docs.github.com/en/copilot/concepts/agents/copilot-cli/about-copilot-cli) to your Datasentinel platform on a Linux host: add the **MCP server**, **sign in** once, install the **Skill** that tells the assistant how to use it, and check that everything is connected.

The same pattern applies to other MCP-and-Skill-capable assistants. The commands below are specific to the standalone GitHub Copilot CLI (the `copilot` command from the `@github/copilot` npm package), not the older `gh copilot` extension.

{% hint style="info" %}
The steps below follow GitHub's documentation, last checked on 6 October 2026. GitHub changes the Copilot CLI often.
{% endhint %}

## Before you start

* The Copilot CLI is installed and you can run `copilot` from a terminal. If it is not yet installed, follow the steps below.
* Your Datasentinel MCP server is reachable over HTTPS at `https://<public-host>/mcp`. See [MCP Server Setup](/manual/ai-connector/server-setup/mcp-server-setup.md) if it is not yet running.

## Install the Copilot CLI

The Copilot CLI is the standalone `copilot` command, which runs on Linux, macOS, and Windows. For the full instructions and alternative install methods, see GitHub's [Installing GitHub Copilot CLI](https://docs.github.com/en/copilot/how-tos/copilot-cli/set-up-copilot-cli/install-copilot-cli) guide.

There are two ways to install it on Linux. They differ mainly in whether Node.js is involved:

* **Install script**: downloads a self-contained `copilot` binary. It does **not** need Node.js or npm, and is the quickest path to a working CLI.
* **npm**: installs the `@github/copilot` package into your Node.js toolchain. It requires **Node.js 22 or later**, and fits in if you already manage tools through npm or want to update the CLI with it.

Pick one:

{% tabs %}
{% tab title="Install script (no Node.js)" %}
Download and run the official installer:

```bash
curl -fsSL https://gh.io/copilot-install | bash
```

This installs a self-contained binary to `~/.local/bin` (or `/usr/local/bin` when run as root) and offers to add that directory to your `PATH` if it is not already there. Override the location with `PREFIX=/custom/path`. No Node.js or npm is required.
{% endtab %}

{% tab title="npm (Node.js 22+)" %}
This method requires **Node.js 22 or later** (npm ships with Node.js, so installing Node.js gives you both). Check your version:

```bash
node --version
npm --version
```

If Node.js is older than 22 or missing, install a current release first. [nvm](https://github.com/nvm-sh/nvm) is the simplest per-user option: it installs Node.js without root and lets you switch versions easily. Install nvm, then restart your shell (or `source ~/.bashrc`) so the `nvm` command is available:

```bash
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash
```

Then install and activate Node.js 22:

```bash
nvm install 22
nvm use 22
```

Alternatively, [NodeSource](https://github.com/nodesource/distributions) provides system-wide packages. Your distribution's own `nodejs` package often lags behind 22, so check the version if you use it.

Finally, install the CLI from npm:

```bash
npm install -g @github/copilot
```

{% endtab %}
{% endtabs %}

Once installed, start the CLI and sign in:

```bash
copilot
```

On first launch it prompts you to sign in with your GitHub account. Once authenticated, you land in an interactive session and can run the setup steps below.

{% hint style="warning" %}
**Name MCP servers with a `datasentinel-` prefix.**

Every Datasentinel MCP server you register must be named starting with `datasentinel-`, for example `datasentinel-production` or `datasentinel-staging`. The Skill discovers Datasentinel servers by this prefix, so a server named otherwise will not be picked up. Use a distinct suffix per platform when you operate more than one (`datasentinel-prod`, `datasentinel-eu`, and so on).
{% endhint %}

## Set it up

{% stepper %}
{% step %}

#### Add the Datasentinel MCP server

For the full reference, see GitHub's [Adding MCP servers for GitHub Copilot CLI](https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers) guide.

Register the server with the streamable-HTTP transport:

```bash
copilot mcp add --transport http datasentinel-production https://<public-host>/mcp
```

`copilot mcp add` writes the server to your **user configuration**, `~/.copilot/mcp-config.json`, so it is available in every directory. A repository can also carry its own servers in `.mcp.json` or `.github/mcp.json`; those load once you trust the folder and take precedence over the user file when names clash (see [Adding per-repository MCP servers](https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers#adding-per-repository-mcp-servers)). You can relocate the whole configuration directory by setting the `COPILOT_HOME` environment variable.

You can also edit `~/.copilot/mcp-config.json` directly instead of using the command above. Each server is a child of the top-level `mcpServers` object, with `"type": "http"` for a remote streamable-HTTP endpoint:

```json
{
  "mcpServers": {
    "datasentinel-production": {
      "type": "http",
      "url": "https://<public-host>/mcp",
      "tools": ["*"]
    }
  }
}
```

{% hint style="info" %}
**Sign in on first use.** The Datasentinel MCP server is protected by OAuth 2.1. Nothing else goes in the configuration: no token, no header. The sign-in is the next step. See [How authentication works](/manual/ai-connector/server-setup/how-authentication-works.md).
{% endhint %}

**Self-signed or invalid certificate**

If your platform serves the `/mcp` endpoint with a self-signed or otherwise invalid TLS certificate, Copilot CLI rejects the connection. The sign-in goes through the same connection, so a rejected certificate blocks it before the login page even opens.

{% hint style="warning" %}
There is **no documented way** to relax certificate verification for a remote MCP server in Copilot CLI. Both install methods run the same native binary with its own embedded Node runtime, and the usual Node variables (`NODE_TLS_REJECT_UNAUTHORIZED`, `NODE_EXTRA_CA_CERTS`) are reported not to apply to remote MCP connections (issue [#4801](https://github.com/github/copilot-cli/issues/4801)). Use a certificate the operating system trusts: one from a public authority, or your internal CA installed in the system trust store. See [Self-signed and untrusted TLS certificates](/manual/ai-connector/troubleshooting/ssl-certificates.md).
{% endhint %}
{% endstep %}

{% step %}

#### Sign in to the platform

**With a browser**

Copilot CLI authenticates to remote MCP servers with OAuth 2.0, using PKCE and dynamic client registration, so nothing is configured on your side (see [OAuth re-authentication](https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference#oauth-re-authentication) in GitHub's command reference). The first time Copilot needs a Datasentinel tool, it opens the Datasentinel login page in your browser and waits for the sign-in.\
Sign in with your **platform login and password**, the same ones as the Datasentinel web interface. The page names the assistant that is asking. After the sign-in, the browser hands the session back to Copilot. From then on the tools run as you.

You sign in once. Copilot renews the session by itself. The login page comes back only after ten days without using the server, or when an administrator ends the session; the server then shows a `needs-auth` status and `/mcp auth datasentinel-production` runs the sign-in again. Your password goes to the login page only. Copilot never sees it, and never asks for a token.

**Without a browser**

On a server without a browser (an SSH session, a build machine), the sign-in still runs in the browser of your laptop.\
Copilot CLI has no paste-the-link mode (issue [#3009](https://github.com/github/copilot-cli/issues/3009)), and its two official headless routes, the device-code flow behind `--device-code` and the client-credentials grant (see [Headless OAuth](https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference#headless-oauth-client_credentials-grant)), need features the Datasentinel authorization server does not provide. What works is an SSH port forward. Pin the port Copilot listens on with `auth.redirectPort` in `~/.copilot/mcp-config.json`, an option introduced in Copilot CLI 1.0.49 and described in its [changelog](https://github.com/github/copilot-cli/blob/main/changelog.md):

```json
{
  "mcpServers": {
    "datasentinel-production": {
      "type": "http",
      "url": "https://<public-host>/mcp",
      "tools": ["*"],
      "auth": { "redirectPort": 19876 }
    }
  }
}
```

Then open the SSH session with that port forwarded:

```bash
# on the laptop: forward the port to the server before starting copilot there
ssh -L 19876:localhost:19876 <user>@<server>
```

{% hint style="warning" %}
The tunnel only exists in an SSH session opened with the `-L` option. If you are already connected without it, log out and reconnect with the command above before starting Copilot. Copilot must run inside that session: in any other session on the same server the callback on `localhost:19876` never reaches the laptop and the sign-in hangs.
{% endhint %}

Copilot CLI does not print the sign-in link in the terminal (issue [#3418](https://github.com/github/copilot-cli/issues/3418)). The workaround reported there is to point the `BROWSER` variable at a command that prints its argument. Set it **before** starting Copilot, because Copilot starts the sign-in on its own as soon as it finds a server that needs authentication:

```bash
BROWSER=echo copilot
```

Then run the sign-in from the Copilot prompt:

1. Type `/mcp`. The dashboard opens on the list of your MCP servers.
2. Select `datasentinel-production`.
3. Select **Authenticate**.

`/mcp auth datasentinel-production` runs the same sign-in in one command (see [OAuth re-authentication](https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference#oauth-re-authentication) in GitHub's command reference).

Open the printed link in the laptop's browser and sign in. The way back to `localhost:19876` travels through the tunnel to Copilot on the server. The general procedure is in [How authentication works](/manual/ai-connector/server-setup/how-authentication-works.md#sign-in-from-a-server-without-a-browser).

**For a script or a scheduled run**

Where nobody can sign in, register the server with a user token as an authorization header instead, with the `--header` option of `copilot mcp add` or the `headers` field of the server entry (both documented in GitHub's [Adding MCP servers](https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/add-mcp-servers) guide and [remote server configuration fields](https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference#remote-server-configuration-fields)). The token is the platform's 24-hour [user token](https://app.gitbook.com/o/DaDQkGCM7r2TghFSBFLQ/s/yE16Xb3IemPxJWydtPOj/implementation/platform-usage/api-reference/access-token). Read it from an environment variable rather than writing it in the configuration:

```bash
copilot mcp add --transport http datasentinel-production https://<public-host>/mcp --header "Authorization: Bearer ${DS_TOKEN}"
```

or, in `~/.copilot/mcp-config.json`, a `headers` entry with the same variable reference:

```json
{
  "mcpServers": {
    "datasentinel-production": {
      "type": "http",
      "url": "https://<public-host>/mcp",
      "tools": ["*"],
      "headers": { "Authorization": "Bearer ${DS_TOKEN}" }
    }
  }
}
```

A server registered with a header never opens the login page.\
When the token expires, the calls fail until a fresh one is set. See [Refresh the user token automatically](/manual/ai-connector/developers/refresh-user-token.md) to keep it current.
{% endstep %}

{% step %}

#### Install the Datasentinel Skill

The Datasentinel Skill is made of several files (a `SKILL.md` entrypoint plus supporting files) and ships as a single archive, `datasentinel-skill.zip`. Download it from <https://app.datasentinel.io/ds-api/download/datasentinel-skill.zip>.

Skills in Copilot CLI are file-based: there is no install command. Create the Skills directory if it does not exist yet, then unzip the archive into it so it produces a `datasentinel/` folder, and Copilot CLI discovers it on the next session.

{% tabs %}
{% tab title="Personal (all your projects)" %}

```bash
mkdir -p ~/.copilot/skills/
unzip datasentinel-skill.zip -d ~/.copilot/skills/
```

{% endtab %}

{% tab title="Project (shared via Git)" %}

```bash
mkdir -p .github/skills/
unzip datasentinel-skill.zip -d .github/skills/
```

{% endtab %}
{% endtabs %}

You should end up with `~/.copilot/skills/datasentinel/SKILL.md` (or `.github/skills/datasentinel/SKILL.md`) alongside the Skill's supporting files. Each Skill lives in its own directory whose `SKILL.md` is the entrypoint. Its frontmatter carries the `description` the assistant uses to decide when to apply the Skill:

```markdown
---
name: datasentinel
description: How to query Datasentinel metrics through the datasentinel-* MCP servers.
---

<instructions for using the Datasentinel MCP tools>
```

{% hint style="info" %}
**Cross-agent location: `.agents/skills`.** Copilot CLI also discovers Skills under the vendor-neutral `.agents/` directory (`~/.agents/skills` for personal Skills, `.agents/skills` in the repo for project Skills) and under `.claude/skills`, so a single `SKILL.md` folder can serve other assistants without duplication. The `~/.copilot/skills` and `.github/skills` paths above are Copilot's own locations; all of them work. See GitHub's [Adding Agent Skills for Copilot CLI](https://docs.github.com/en/copilot/how-tos/copilot-cli/customize-copilot/add-skills) reference.
{% endhint %}
{% endstep %}

{% step %}

#### Check your configuration

Inside an interactive `copilot` session, list the configured servers and their connection status:

```
/mcp show
```

A healthy entry shows the server connected with its tools available. A server you have not signed in to yet shows a `needs-auth` status. The sign-in runs the first time a tool is needed, or on demand with `/mcp auth datasentinel-production`. If it shows an error, check the URL and that the server is up. Inspect one server in detail (transport, URL, status):

```
/mcp show datasentinel-production
```

The companion slash commands let you `/mcp add`, `/mcp edit`, `/mcp enable`, and `/mcp disable` a server. To remove one:

```
/mcp delete datasentinel-production
```

**Approve the Datasentinel tools**

The first time the assistant calls a Datasentinel tool, Copilot CLI prompts you to allow it. You can allow it once, for the rest of the session, or for the current location. A location approval is saved to `~/.copilot/permissions-config.json` and applies to the Git repository you are in (or the working directory outside a repository), so the prompt does not come back there.

To skip the prompts for every tool of the server at once, name the server in the `--allow-tool` option when you start Copilot; a tool name in parentheses restricts the rule to that tool:

```bash
copilot --allow-tool='datasentinel-production'
copilot --allow-tool='datasentinel-production(get_platform_status)'
```

The Datasentinel tools only read monitoring data, so allowing the whole server is safe. `--allow-all-tools` (or `/allow-all` inside a session, alias `/yolo`) approves every tool of every kind, including shell commands and file writes; use it with care. `/reset-allowed-tools` revokes what was granted during the session. The syntax and the file format are in GitHub's [Allowing and denying tool use](https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools) guide.
{% endstep %}
{% endstepper %}

Once the server shows as connected and the Skill is in place, run through the checks below to confirm the end-to-end flow.

## How the Skill loads

The Datasentinel Skill loads on demand. Copilot reads every Skill's name and `description` up front, and applies the full instructions automatically when your prompt relates to Datasentinel: asking about PostgreSQL performance, instances, sessions, or the platform itself is enough. One Skill serves every platform, because it discovers all the `datasentinel-*` MCP servers you registered, so adding a second platform needs no Skill change.

If Copilot answers generically instead (no Datasentinel tool calls in the response), load the Skill manually:

* Name it with a slash in the prompt: `Use the /datasentinel skill to check the platform status.`
* Run `/skills list` to confirm the Skill is discovered, and `/skills` to check it is enabled.

If the Skill is missing from `/skills list`, re-check the unzip location from the setup step and start a new session.

## Test the MCP server and Skill

Run these checks inside an interactive `copilot` session.

You exercise the Skill by asking in plain language and letting it drive the MCP tools (see [How the Skill loads](#how-the-skill-loads) above). The Datasentinel Skill recognises four built-in checks. Run them in order:

| Ask Copilot for…         | What it does                                                                                             |
| ------------------------ | -------------------------------------------------------------------------------------------------------- |
| `datasentinel help`      | Displays the Skill's help, listing the available commands.                                               |
| `datasentinel platforms` | Lists every MCP server (platform) the Skill discovered by its `datasentinel-` prefix.                    |
| `datasentinel status`    | Checks the platform status, confirming the MCP server answers and the sign-in is in place.               |
| `datasentinel whoami`    | Shows who the session is connected as: platform, identity, privilege, real-time access, style, language. |

These four are the setup checks. The full command list, with what each one needs, is in the [Skill commands reference](/manual/ai-connector/use-the-assistant/skill-commands.md).

Start with `datasentinel help` to confirm the Skill responds. It needs no sign-in. Then run `datasentinel platforms` to verify your server is discovered. Each `datasentinel-*` MCP server you registered should appear in the list. Run `datasentinel status` to confirm the platform is reachable and the MCP tools return live data. The first call opens the login page if you have not signed in yet. Finally, `datasentinel whoami` confirms the account the session runs under and the communication style the assistant will use.

{% hint style="success" %}
If `datasentinel status` reports a healthy platform, the MCP server and the Skill are wired together correctly. You can now ask the assistant questions about your instances in plain language.
{% endhint %}

{% hint style="info" %}
**Server not discovered? Ask the assistant to find the root cause.**

If `datasentinel platforms` lists nothing, or your server is missing from it, ask Copilot to debug the setup rather than hunting by hand. It can run `/mcp show`, read `~/.copilot/mcp-config.json`, and probe the endpoint itself, so it usually pinpoints the cause in one pass.

Ask it something like:

```
The datasentinel-production MCP server is not discovered. Investigate and find the root cause: check my MCP configuration, the connection status of the server, and whether the /mcp endpoint answers.
```

Typical causes it surfaces: a server name that misses the `datasentinel-` prefix, a typo in the URL, a disabled server, a sign-in that was never completed, a rejected TLS certificate, or a platform that is down.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.datasentinel.io/manual/ai-connector/connect-a-cli-assistant/configure-copilot-cli.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.