Forem: Mikoshiba Kyu

Managing GitHub Copilot CLI MCP Server Configuration in Your Repository

Mikoshiba Kyu — Sat, 20 Dec 2025 09:58:55 +0000

Introduction

When developing with GitHub Copilot CLI, MCP server configuration typically depends on each developer's individual environment.
However, in team development, there's a need to "standardize the MCP servers used within the repository."

This article explains how to include GitHub Copilot CLI MCP configuration in your repository using VSCode + WSL2 + DevContainers environment.

Background and Challenges

Environment

VSCode
WSL2 + DevContainers

Why Include MCP Configuration in the Repository?

Required MCP servers differ based on project characteristics.
For example, Chrome DevTools MCP is useful for web application development, but unnecessary for other types of projects.
On the other hand, code analysis tools like Serena might be desired across all repositories.

Currently, you need to document "Please install this MCP server" in the README's development environment setup section.
This requires each developer to manually install, leading to version differences or some people skipping installation due to inconvenience.
As a result, discrepancies in development environments within the team tend to arise.

Claude Code allows you to load MCP configuration by placing a .mcp.json file,
and also provides a mechanism called Claude Code Plugin for creating and sharing plugin store repositories.

Both of these features would be incredibly desirable for GitHub Copilot...
However, the current GitHub Copilot CLI requires workarounds.

The Challenge

In GitHub Copilot CLI, when you add configuration using the /mcp add command, it's saved by default in the ~/.copilot directory.
GitHub Copilot CLI then references this configuration in the home directory to operate.

In other words, MCP configuration sits outside the repository as a personal user setting.

Solution

1. Place MCP Configuration File in Repository

First, place .copilot/mcp-config.json in the project root directory.
Here's an example with Serena configuration.

{
  "mcpServers": {
    "serena": {
      "type": "local",
      "command": "uvx",
      "tools": ["*"],
      "args": [
        "--from",
        "git+https://github.com/oraios/serena",
        "serena",
        "start-mcp-server",
        "--context",
        "ide-assistant"
      ],
      "env": {}
    }
  }
}

2. Exclude Unnecessary Files in .gitignore

The .copilot directory generates files specific to individual environments, such as logs and config.json.
Since only the MCP configuration file should be committed, exclude them in .gitignore.

+ .copilot/logs/
+ .copilot/config.json

3. Change GitHub Copilot CLI Configuration Directory in DevContainers

Configure DevContainers' postCreateCommand to execute postCreateCommand.sh,
where you change the GitHub Copilot CLI configuration directory.
Below is an example for zsh, specifying the project root.

+ GH_CLI_CONFIG_DIR="/workspaces/your-repo"

+ if ! grep -q 'export XDG_CONFIG_HOME=' ~/.zshrc; then
+     echo "export XDG_CONFIG_HOME=\"$GH_CLI_CONFIG_DIR\"" >> ~/.zshrc
+ fi

4. Verification

Rebuild the DevContainer and launch GitHub Copilot CLI.
With the /mcp show command, you can confirm that Serena is loaded as shown below.

● MCP Server Configuration:

  • serena (local): Command: uvx

  Total servers: 1
  Config file: /workspaces/your-repo/.copilot/mcp-config.json

The Config file path points to .copilot/mcp-config.json within the repository.

Conclusion

Now we can handle MCP servers at the same level as Claude Code's .mcp.json.

Looking at Awesome Copilot, it seems the philosophy is that MCP server configuration is a personal setting.
I hope MCP configuration will migrate to a similar structure, making this article obsolete.

References

I created a Boiler Plate for creating Web Apps with Google Apps Script.

Mikoshiba Kyu — Tue, 02 Jul 2024 02:24:13 +0000

GAS-WebApp-BoilerPlate

Boilerplate for creating web apps with Google Apps Script.

We expect to develop in TypeScript and React.

Mikoshiba-Kyu / gas-webapp-boilerplate

Template for creating web apps with Google Apps Script

GAS-WebApp-BoilerPlate

English / 日本語

Boilerplate for creating web apps with Google Apps Script.
We expect to develop in TypeScript and React.

Feature

DevContainer is used
Vite and clasp generate files for eventual deployment in Google Apps Script
Unit tests can be created with Vitest and E2E tests with Playwright

Quick Start

git clone https://github.com/Mikoshiba-Kyu/gas-webapp-boilerplate.git

Overview of Project Structure

The core development code is placed under the src folder for the front end and back end, respectively.

📁 src
├── 📁 backend
│   ├── 📁 serverFunctions
│   │   ├── 📄 index.ts
│   │   └── 📄 and more...
│   └── 📄 main.ts
└── 📁 frontend
    ├── 📄 main.tsx
    └── 📄 and more...

The yarn build creates files for Google Apps Script in the gas/dist folder.

📁 gas
├── 📁 dist
│   ├── 📄 index.html
│   └── 📄 main.js
└── 📄 appsscript.json

Other folders are described below.

.github Preset Github Actions for E2E…

View on GitHub

Feature

DevContainer is used
Vite and clasp generate files for eventual deployment in Google Apps Script
Unit tests can be created with Vitest and E2E tests with Playwright

Quick Start

git clone https://github.com/Mikoshiba-Kyu/gas-webapp-boilerplate.git

Overview of Project Structure

The core development code is placed under the src folder for the front end and back end, respectively.

📁 src
├── 📁 backend
│   ├── 📁 serverFunctions
│   │   ├── 📄 index.ts
│   │   └── 📄 and more...
│   └── 📄 main.ts
└── 📁 frontend
    ├── 📄 main.tsx
    └── 📄 and more...

The yarn build creates files for Google Apps Script in the gas/dist folder.

📁 gas
├── 📁 dist
│   ├── 📄 index.html
│   └── 📄 main.js
└── 📄 appsscript.json

Other folders are described below.

.github Preset Github Actions for E2E test execution.
.husky Preset lint at pre commit time.
e2e Stores Playwright test files.

Development

Launch DecContainer

Clone the repository and start DevContainer in any way you wish.

Front-end implementation

Implement the front-end side in src/frontend.

Common UI frameworks, state management libraries, etc. can be used.

Back-end implementation

Google Apps specific classes such as SpreadsheetApp cannot be used directly from the front end.

You must call the function exposed to global in backend/main.ts via gas-client from the front end.

// backend/main.ts

import { sampleFunction } from './serverFunctions'

declare const global: {
  [x: string]: unknown
}

// This function is required to run as a webApp
global.doGet = (): GoogleAppsScript.HTML.HtmlOutput => {
  return HtmlService.createHtmlOutputFromFile('dist/index.html')
}

// Create the necessary functions below.
global.sampleFunction = sampleFunction

// frontend/App.tsx

import { GASClient } from 'gas-client'
const { serverFunctions } = new GASClient()

...
...

const handleButton = async () => {
    if (import.meta.env.PROD) {
        try {
        const response: number = await serverFunctions.sampleFunction(count)
        setCount(response)
        } catch (err) {
        console.log(err)
        }
    } else {
        setCount(count + 1)
    }
}

...
...

🗒️Notes

In the above example, import.meta.env.PROD is used to branch by environment.

If created by yarn build and deployed in GAS, the environment uses serverFunction,
And if it is running locally by yarn dev, it will work in an alternative way.

Creating and running tests

Unit testing

$ yarn test:unit

For front-end and unit testing, use Vitest.

If you want to test Google Apps specific functions created in serverFunctions, you need to mock them.

E2E testing

$ yarn test:e2e

Playwright is used for E2E testing.

The URL of an already running GAS web app must be specified as baseURL.

// playwright.config.ts

...
...

use: {
    /* Base URL to use in actions like `await page.goto('/')`. */
    baseURL: process.env.PLAYWRIGHT_BASE_URL || 'your apps url',
  },

...
...

⚠️ Important
When conducting E2E testing, the target application must be made available to everyone.

Deployment

First, compile with Vite.

$ yarn build

If you are not logged in to clasp, log in.

$ clasp login

Create a new project if one has not already been created.

When you create a project as follows, a new file appsscript.json will be created in the root.

If you want to use the one already placed in the gas folder, you can delete it.

$ clasp create

? Create which script?
  standalone
  docs
  sheets
  slides
  forms
> webapp
  api

🗒️Notes

If you are using a project that has already been created,

manually create .clasp.json in the root and specify the scriptId directly.

🗒️Notes

Set "timeZone" in gas/appscript.json according to your situation.

Replace the rootDir in the created .clasp.json with the path to the gas folder of the project.

{
  "scriptId": "********",
  "rootDir": "/workspaces/gas-webapp-boilerplate/gas"
}

Execute deployment.

$ clasp push
$ clasp deploy

To open the deployed project page in a browser, use the following command.

$ clasp open

Released a Desktop Client App "itos" for ChatGPT

Mikoshiba Kyu — Tue, 10 Oct 2023 05:53:07 +0000

Overview

We have released a desktop app called itos for conversing with ChatGPT.
It is compatible with Windows, MacOS, and Linux.

The release page is available here.
Please download the installer compatible with your OS and use it.

A ChatGPT API KEY is required to use it.
The available models are gpt-4 and gpt-3.5-turbo.

Features

It is possible to display multiple conversations side by side. Each conversation can be rearranged, and you can toggle between visibility and non-visibility.
This makes it easy to handle applications such as having discussions on related topics with ChatGPT.
You can specify a prompt for the entire conversation (role: "system" in the ChatGPT API).
You can set your own avatar icon and an avatar icon for ChatGPT for each conversation.
Together with the previously mentioned prompt setting, you can play games such as having simulated conversations with specific characters.
The app supports both English and Japanese display languages, and it also supports two theme settings.

Development

We used Tauri as the application framework.
At this point, all implementations were done only in TypeScript, and there was no need for Rust.
The front-end uses React and MUI. We developed freely using only what we like.

Afterword

If my product could be a great experience for you, Please buy me a hot cup of coffee. Thank you.
buymeacoffee.com

Forem: Mikoshiba Kyu

Managing GitHub Copilot CLI MCP Server Configuration in Your Repository

Introduction

Background and Challenges

Environment

Why Include MCP Configuration in the Repository?

The Challenge

Solution

1. Place MCP Configuration File in Repository

2. Exclude Unnecessary Files in .gitignore

3. Change GitHub Copilot CLI Configuration Directory in DevContainers

4. Verification

Conclusion

References

I created a Boiler Plate for creating Web Apps with Google Apps Script.

GAS-WebApp-BoilerPlate

Mikoshiba-Kyu / gas-webapp-boilerplate

Template for creating web apps with Google Apps Script

GAS-WebApp-BoilerPlate

Feature

Quick Start

Overview of Project Structure

Feature

Quick Start

Overview of Project Structure

Development

Launch DecContainer

Front-end implementation

Back-end implementation

Creating and running tests

Unit testing

E2E testing

Deployment

Released a Desktop Client App "itos" for ChatGPT

Overview

Features

Development

Afterword

Related Links