Getting Started

This page is the part that is the same for GitHub Copilot, Codex and ChatGPT. Once you have done it, go to your assistant's page for the install steps.

Using Claude instead? See Getting Started with Claude.

What you need

Your instance address, the hostname you use for Foundry Connect, for example foundry.your-org.edu. Every assistant needs this, and it is the one thing a published plugin cannot know for you.
An account on that instance, with access to at least one project.
The assistant itself, installed and signed in to its own vendor account. That sign-in is separate from Foundry Connect.

Find everything you need in Foundry Connect

You do not have to assemble the address or the commands by hand. Foundry Connect shows you both, filled in for your own instance.

Sign in, open Profile, then the Connect AI Assistants tab. It gives you:

The connector URL for your instance. It is the same address for every assistant.
The commands for your assistant, ready to copy. Choose Claude, Copilot CLI, Codex CLI or ChatGPT from the row of buttons at the top and the steps below change to match.
Your active connections, each with a Revoke button.

Your choice is kept in the address bar, so a link ending in ?client=codex opens straight on that assistant.

ChatGPT appears in the picker too. Rather than leaving you to hunt for a route that does not exist, it says plainly that there is no self serve way to point ChatGPT at your instance yet, and sends you to Codex CLI or Claude instead.

The tab was called Connect to Claude in earlier releases

It was renamed once it covered more than one assistant. The address did not change, so existing links and bookmarks still work.

Taking the Personal Access Token route instead? That screen now writes the configuration snippet for Copilot CLI and Codex CLI as well as Cursor and VS Code. Both of the new ones read the token from an environment variable, so it is never written into the file itself.

Connect once

Two ways to authenticate. Which you use depends on the assistant.

OAuth (preferred)

The assistant sends you to Foundry Connect, you approve access once, and no token is ever written into a configuration file. This is the better option wherever it works.

It relies on the assistant following the sign-in address Foundry Connect names when it refuses an unauthenticated request. Copilot and Claude do exactly that. Codex does not: it builds an address itself, which is why it needs a newer instance (see below).

A Personal Access Token (works everywhere)

Generate an MCP token under Personal Access Tokens. It must carry the via_mcp_ prefix, so create it with the MCP usage type; a general purpose token is rejected on every authentication path.

Supply it as a header, or through your assistant's own token setting. Copilot and Codex both expand environment variables in those settings, so the token itself does not have to sit in the file as literal text.

OAuth on Codex needs Foundry Connect 2.22.0 or later

Codex discovers its sign-in details by constructing a path-suffixed address itself, and it never falls back to the plain one. Instances before 2.22.0 do not answer there, so codex mcp login cannot complete against them. Use a Personal Access Token on an older instance.

Your first conversational action

Once connected, ask for something read-only. A good first request, because it proves authentication, tool discovery and your project access all at once:

What pipelines do I have access to on Foundry Connect?

If that returns a list, you are connected. If it returns nothing, or the assistant says it has no such tool, the connection is not established: go back to your assistant's page and check the "did it work" step there.