AI features can make an open source project shine. At least, until setup asks for a paid inference API key.  Requiring contributors or even casual users to bring their own large language model (LLM) key stops adoption in its tracks: $ my-cool-ai-tool Error: OPENAI_API_KEY not found Developers may not want to buy a paid plan just to try out your tool, and self hosting a model can be too heavy for laptops or GitHub Actions runners.  GitHub Models solves that friction with a free, OpenAI-compatible inference API that every GitHub account can use with no new keys, consoles, or SDKs required. In this article, we’ll show you how to drop it into your project, run it in CI/CD, and scale when your community takes off. Let’s jump in. The hidden cost of “just add AI” AI features feel ubiquitous today, but getting them running locally is still a challenge for a few reasons: Paid APIs: The simplest path is to ask users for an OpenAI or Anthropic key. That’s a non-starter for many hobbyists and students because paid APIs are too expensive. Local models: Running a 2 B-parameter LLM can work for lightweight tasks, but anything that requires more intelligence will quickly blow past typical laptop memory — let alone the 14 GB container that backs a GitHub Actions runner. Docker images and weights: You can bundle a model with your app, but distributing multi-gigabyte weights balloons install size and slows CI. Every additional requirement filters out potential users and contributors. What you need is an inference endpoint that’s: Free for public projects Compatible with existing OpenAI SDKs Available wherever your code runs, like your laptop, server, or Actions runner That’s what GitHub Models provides. GitHub Models in a nutshell What it is: A REST endpoint that speaks the chat/completions spec you already know. What you get: A curated set of models (GPT-4o, DeepSeek-R1, Llama 3, and more) hosted by GitHub. Who can call it: Anyone with a GitHub Personal Access Token (PAT), or a repository’s built-in GITHUB_TOKEN when you opt-in via permissions. How much it costs: Free tier for all personal accounts and OSS orgs; metered paid tier unlocks higher throughput and larger context windows. Because the API mirrors OpenAI’s, any client that accepts a baseURL will work without code changes. This includes OpenAI-JS, OpenAI Python, LangChain, llamacpp, or your own curl script. How to get started with GitHub Models Since GitHub Models is compatible with the OpenAI chat/completions API, almost every inference SDK can use it. To get started, you can use the OpenAI SDK: import OpenAI from “openai”; const openai = new OpenAI({ baseURL: “https://models.github.ai/inference/chat/completions”, apiKey: process.env.GITHUB_TOKEN // or any PAT with models:read }); const res = await openai.chat.completions.create({ model: “openai/gpt-4o”, messages: [{ role: “user”, content: “Hi!” }] }); console.log(res.choices[0].message.content); If you write your AI open source software with GitHub Models as an inference provider, all GitHub users will be able to get up and running with it just by supplying a GitHub Personal Access Token (PAT). And if your software runs in GitHub Actions, your users won’t even need to supply a PAT. By requesting the models: read permission in your workflow file, the built-in GitHub token will have permissions to make inference requests to GitHub Models. This means you can build a whole array of AI-powered Actions that can be shared and installed with a single click. For instance: Code review or PR triage bots Smart issue tagging workflows Weekly repository activity report generators And anything else that a GitHub Action can do Plus, using GitHub Models makes it easy for your users to set up AI inference. And that has another positive effect: it’s easier for your contributors to set up AI inference as well. When anyone with a GitHub account can run your code end to end, you’ll be able to get contributions from the whole range of GitHub users, not just the ones with an OpenAI key. Zero-configuration CI with GitHub Actions Publishing an Action that relies on AI used to require users to add their inference API key as a GitHub Actions secret. Now you can ship a one-click install: yaml # .github/workflows/triage.yml permissions: contents: read issues: write models: read # 👈 unlocks GitHub Models for the GITHUB_TOKEN jobs: triage: runs-on: ubuntu-latest steps: – uses: actions/checkout@v4 – name: Smart issue triage run: node scripts/triage.js The runner’s GITHUB_TOKEN carries the models:read scope, so your Action can call any model without extra setup. This makes it well suited for: Automated pull request summaries Issue deduplication and tagging Weekly repository digests Anything else you can script in an Action Scaling when your project takes off The GitHub Models inference API is free for everyone. But if you or your users want to do more inference than the free rate limits allow, you can turn on paid inference in your settings for significantly larger context windows and higher requests-per-minute.  When your community grows, so will traffic. So it’s important to consider the following:  Requests per minute (RPM): While the free tier offers default limits, the paid tier offers multiples higher. Context window: Free tier tops out at standard model limits; paid enables 128k tokens on supported models. Latency: The paid tier runs in its own separate deployment, so you’re not in the same queue as free tier users. To get started, you can enable paid usage in Settings > Models for your org or enterprise. Your existing clients and tokens will keep working (but they’ll be faster and support bigger contexts). Take this with you LLMs are transforming how developers build and ship software, but requiring users to supply their own paid API key can be a barrier to entry. The magic only happens when the first npm install, cargo run, or go test just works. If you maintain an AI-powered open source codebase, you should consider adding GitHub Models as a default inference provider. Your users already have free AI inference via GitHub, so there’s little downside to letting them use it with

Model Context Protocol (MCP) enables AI agents to connect to external tools and data sources without having to implement API-specific connectors. Whether you’re extracting key data from invoices, summarizing support tickets, or searching for code snippets across a large codebase, MCP provides a standardized way to connect LLMs with the context they need.  Below we’ll dig into why security is such a crucial component to MCP usage, especially with a recent specification release, as well as how developers of both MCP clients and MCP servers can build secure integrations from the get-go. Why security matters for MCP Unlike traditional APIs that serve known clients in somewhat controlled environments, MCP servers act as bridges between AI agents and an unlimited number of data sources that can include sensitive enterprise resources. So, a security breach won’t just compromise data — it can give malicious actors the ability to manipulate AI behavior and access connected systems. To help prevent common pitfalls, the MCP specification now includes security guidelines and best practices that address common attack vectors, like confused deputy problems, token passthrough vulnerabilities, and session hijacking. Following these patterns from the start can help you build systems that can handle sensitive tools and data. Understanding the MCP authorization The MCP specification uses OAuth 2.1 for secure authorization. This allows MCP, at the protocol level, to take advantage of many modern security capabilities, including: Authorization server discovery: MCP servers implement OAuth 2.0 Protected Resource Metadata (PRM) (RFC 9728) to advertise the authorization servers that they support. When a client attempts to access a protected MCP server, the server will respond with a HTTP 401 Unauthorized and include a WWW-Authenticate header pointing to the metadata endpoint. Dynamic client registration: This is automatic client registration using OAuth 2.0 Dynamic Client Registration Protocol (RFC 7591). This removes the need for manual client setup when AI agents connect to MCP servers dynamically. Resource indicators: The specification also mandates RFC 8707 Resource Indicators, ensuring that tokens are bound to specific MCP servers. This prevents token reuse attacks and helps maintain clear security boundaries. Even with the latest changes to authorization specs, like the clean split between the responsibilities of the authorization server and the resource server, developers don’t need to worry about implementing security infrastructure from scratch. (Because the requirement to follow the OAuth2.1 conventions didn’t change.) So developers can just use off-the-shelf authorization servers and identity providers.  Because MCP requires implementers to snap to OAuth 2.1 as the default approach to authorization, this also means that developers can use existing OAuth libraries to build the authorization capabilities into their MCP servers without anything super-custom. This is a massive time and effort saver. The complete authorization flow When it comes to connecting to protected MCP servers, a MCP client will need to somehow find out what credentials the server needs. Luckily, because of the aforementioned discovery mechanism, this is a relatively straightforward flow: Discovery phase. MCP client attempts to access MCP server without credentials (that is a token). Server response. MCP server returns a HTTP 401 Unauthorized response with a metadata URL in the WWW-Authenticate header. Metadata retrieval. MCP client fetches Protected Resource Metadata, parses it, and then gets the authorization server endpoints. Client registration. MCP client automatically registers with authorization server (if supported). Some clients may be pre-registered. Authorization request. MCP client initiates OAuth flow with Proof Key for Code Exchange (PKCE) and the resource parameter. User consent. The user authorizes access through the authorization server. Token exchange. MCP client exchanges authorization code for access token. Authenticated requests. All subsequent requests from MCP client to MCP server include Bearer token. Nothing in the flow here is MCP-specific, and that’s the beauty of MCP snapping to a common industry standard. There’s no need to reinvent the wheel because a robust solution already exists. Implementing authorization in MCP Most OAuth providers work well for MCP server authorization without any additional configuration, though one of the more challenging gaps today is the availability of Dynamic Client Registration. However, support for that feature is slowly rolling out across the identity ecosystem, and we expect it to be more common as MCP gains traction. Aside from the authorization server, when implementing authorization for your MCP server, you will need to consider several key components and behaviors: PRM endpoint. The MCP server must implement the /.well-known/oauth-protected-resource endpoint to advertise supported authorization server scopes. The MCP TypeScript SDK already integrates this capability natively, with other MCP SDK support coming very soon. Token validation middleware. You need to make sure that your MCP server is only accepting tokens meant for it. Many open source solutions, like PyJWT, can help you here by: Extracting Bearer tokens from Authorization headers Validating token signatures using your OAuth provider’s JSON Web Key Sets (JWKS) endpoint Checking token expiration and audience claims Ensuring tokens were issued specifically for your MCP server (this part is critical for the security of your infrastructure) Error handling. Your MCP server will need to return proper HTTP status codes (HTTP 401 Unauthorized for missing/invalid tokens, HTTP 403 Forbidden for insufficient permissions) with appropriate WWW-Authenticate headers. Anthropic, together with the broader MCP community, is working on integrating a lot of these capabilities directly into the MCP SDKs, removing the need to implement many of the requirements from scratch. For MCP server developers, this will be the recommended path when it comes to building implementations that conform to the MCP specification and will be able to work with any MCP client out there. Handling multi-user scenarios Multi-tenancy in MCP servers introduces unique security challenges that go beyond simple authorization and token validation. When your MCP server handles requests from multiple users — each with their own identities, permissions, and data — you must enforce strict boundaries to prevent unauthorized access and data leakage. This is a classic “confused deputy” problem, where a legitimate user could inadvertently trick the MCP server into accessing resources they shouldn’t. OAuth tokens are the foundation for securely identifying users. They often contain

What started in 2006 with just 40 farm families in western Kenya has grown into a powerful movement. Today, One Acre Fund serves 5 million farm families across ten countries in eastern and southern Africa. Their ambitious goal? By 2030, they aim to support 10 million farm families annually. How? By using open source technology and AI, aiming to generate an astounding $1 billion in new revenue for these communities. Cultivating impact with technology For smallholder farmers — those typically working with an acre or less of land — intensifying agriculture is crucial for their prosperity. This process of producing more food with the same amount of land, not only brings higher crop yields, but stimulates the economy, strengthens community, and enables farmers to scale. One Acre Fund’s core mission is to empower these farmers, providing a direct pathway out of poverty. But unlike traditional microfinance, they don’t just loan cash. Instead, they provide vital farm resources like fertilizer and seed, plus training and services, directly equipping farmers with the tools they need to succeed. They also help the farmers they serve to improve their soil health and plant trees to not only increase yields but also help farmers be more resilient to weather changes due to climate change. In the past, farmers used to fear using technology. But, as we provide training to them, they’re now eager to use it. Blaise Murame, Regional Lead, One Acre Fund Technology is at the heart of One Acre Fund’s rapid growth. They’ve transitioned from an entirely analog approach — meeting farmers in the field with paper records — to a highly digitized system. This transformation has revolutionized their operations, making everything from logistics and delivery to farmer registration and the development of training materials more efficient. Farmers, initially hesitant, are now eager to embrace this tech, after receiving resources and tools on time and achieving their goals faster than ever before. Growing products to empower farmers A significant part of One Acre Fund’s tech leap comes from their adoption of GitHub Copilot.  Since the coming of GitHub Copilot, the time it used to take us three weeks, that development work can be finished within a week. That’s affecting our goals – we’re able to set more goals than last year. Yididiya Gebredingel, Developer, One Acre Fund By introducing GitHub Copilot, One Acre Fund has been able to move much faster on their development, and they can focus on the pieces that are actually creating impact in the field. This acceleration has enabled them to set and achieve more goals, with developers completing projects three times faster and over 30% of their work being assisted by AI. As a nonprofit, working with some of the world’s poorest populations means operating on razor-thin margins.This makes the cost-effectiveness of their solutions paramount. Open source technology provides the ideal balance, offering both “solution maturity and solution flexibility” without the burden of exponentially growing license fees as they scale. Embracing the open source community is a strategic move for One Acre Fund, as they’ve migrated most of their core operational systems to open source to leverage collaborative development and community support. As a nonprofit, we can’t tolerate license fees that will grow exponentially as we scale. Open source gives us the right balance between solution maturity and solution flexibility. Sarah Hylden, Global Director of Operations, One Acre Fund Ultimately, One Acre Fund believes that if you have an intervention that works to create a sustainable pathway out of poverty for farmers, and you know it works, then you have a moral obligation to scale it. And with the help of GitHub Copilot, they are doing just that — moving faster and making a greater impact in the lives of millions of farm families. Explore a better way of working by trying GitHub Copilot for free today, or if you’re a nonprofit organization, check out GitHub for Nonprofits for exclusive discounts. The post Scaling for impact: How GitHub Copilot supercharges smallholder farmers appeared first on The GitHub Blog. ​ Open Source, Social impact, GitHub Copilot The GitHub Blog

Running the Model Context Protocol (MCP) server locally works, but managing Docker, rotating access tokens, and pulling updates is a hassle. GitHub’s managed MCP endpoint eliminates these infrastructure headaches, letting you focus on what you love — shipping code. In this 201-level tutorial, we’ll walk through upgrading from the local MCP setup to GitHub’s managed endpoint. You’ll get OAuth authentication, automatic updates, and access to toolsets that open the door to richer AI workflows you simply can’t pull off with a bare‑bones local runtime. You’ll also learn how to customize tool access with read-only modes, streamline your AI workflows with dynamic toolsets, and get ready for agent-to-agent collaboration using GitHub Copilot. The GitHub remote  MCP server is GitHub’s fully hosted, always‑up‑to‑date implementation of MCP Instead of wrestling with Docker and personal access tokens on your machine, you point your IDE or agent host to https://api.githubcopilot.com/mcp/ and authenticate once with OAuth. GitHub handles the rest. With our server, we enable the following toolsets by default, but you can disable anything you don’t need with a simple flag when you start the server:  Repository intelligence: Search code, stream files, and open pull requests without a local clone. Issue and pull request automation: File, triage, label, review, and even merge from a single agent prompt. CI/CD visibility: Inspect workflow runs, fetch logs, and re‑run failed jobs right inside chat. Security insights: Surface code scanning and Dependabot alerts so fixes land before exploits do. Fine‑grained controls: Toggle specific toolsets or flip the server to read‑only for extra safety. Get started > But first, why switch to our hosted server?  Running the open source MCP server locally works, but it carries hidden costs. Here’s what changes when you go remote: Local Docker server Hosted MCP endpoint Maintain a Docker image, upgrade manually GitHub patches and upgrades automatically Manage personal‑access tokens (PATs) Sign in once with OAuth; scopes handled for you Expose the server on localhost only Reachable from any IDE or remote‑dev box Full write access unless you customise the binary Built-in read‑only switch and per‑toolset flags If you need an air‑gapped environment, stick with local. For most teams, the hosted server eliminates infrastructure work and lets you focus on automation. With that, let’s dive in. A few things you need before you get started: GitHub Copilot or Copilot Enterprise seat VS Code 1.92+ (or another MCP‑capable client) Network access to https://api.githubcopilot.com A test repository to experiment with Step 1: Install the remote MCP server Setting up GitHub’s remote MCP server server is a breeze compared to local Docker-based installations. Hosted by GitHub, it eliminates the need for managing Docker containers or manually handling updates, offering a streamlined, cloud-native experience. How to install the remote server on VS Code or VS Code Insiders: Open the command palette and run:> GitHub MCP: Install Remote Server Complete the OAuth flow to connect your GitHub account. Restart the server to finish setup. For any other client Set the server URL to: https://api.githubcopilot.com/mcp/ Then authenticate when prompted. Validate your connection with a quick check curl -I https://api.githubcopilot.com/mcp/healthz # HTTP/1.1 200 OK If you see 200 OK, you’re good to go. Once installed, the remote server replaces the local one, and you’re ready to roll. That means no more Docker or tokens, just a simple integration. Step 2: Configure access controls Use read-only mode for safe exploration. Working in a sensitive environment? Testing in production? Demoing to stakeholders? Flip the server to read-only mode: { “servers”: { “github”: { “type”: “http”, “url”: “https://api.githubcopilot.com/mcp/”, “mode”: “read-only” } } } The agent can read issues, pull requests, and code but can’t push changes. Perfect for code reviews where you want context without risk. Use case: Pull request viewer Need to review pull requests without modifying anything? This setup gives you safe, read-only access — perfect for browsing changes, leaving comments, or gathering context without risk of altering code. Go to the GitHub MCP server repo. Navigate to the “Remote Server” section. Choose the pull request read-only variant. Click Install Read Only. You’ll now see tools like listPullRequests, getPullRequest, and searchPullRequests, but no write access. And since these tools don’t make changes, VS Code skips the permission prompts for a seamless experience. Limit scope with selective toolsets Keep both developers and agents focused by exposing only the tools you need with the following command: “toolsets”: [“context”, “issues”, “pull_requests”] Add this array next to the mode field to hide everything else. Step 3: Try it out with these three hands-on examples Want to see how Copilot agent mode works in practice? These real-world examples show how the agent can handle everyday developer tasks — like managing pull requests, debugging workflows, and triaging security alerts — without needing local setup or manual digging. Just prompt and go. Example 1: Add a CODEOWNERS file and open a pull request Open your repo ➜ Ask Copilot Agent. Prompt your agent: “Add a CODEOWNERS file for /api/** assigning @backend-team, then open a draft pull request.” The agent will: Use repos.create_file to add the CODEOWNERS file. Call pull_requests.open to create the pull request. Execute pull_requests.request_reviewers to assign reviewers. No local cloning, no manual file creation. Just prompt and ship. Example 2: Debug a failed workflow Prompt: “Why did the release.yml job fail last night?” The agent pulls logs with actions.get_workflow_run_logs, analyzes the stack trace, and suggests fixes. It’s like having a senior engineer review your CI/CD failures. Example 3: Triage security alerts Prompt: “List critical Dependabot alerts across all my repos and create issues for each.”  The server returns alerts via dependabot.list_dependabot_alerts, then the agent creates focused issues only where needed. Step 4: Troubleshooting tips with the GitHub remote MCP server  Symptom Likely cause Fix 401 Unauthorized on install Left‑over GITHUB_TOKEN env var Unset the var and rerun OAuth flow Tools don’t appear Corporate proxy blocks api.githubcopilot.com Add proxy settings or allowlist the domain Model times out Large toolset enabled Restrict to needed toolsets only Step 5: Streamline your workflow with dynamic toolsets The full MCP server includes over 70 tools, and, while

What makes open source work, and why do so many of us keep showing up to build together? On the GitHub Podcast, we dive into the stories behind the code: the projects, the people, and the ideas shaping the open source ecosystem. At GitHub, we know open source has always been the launchpad for what’s next. But 2025 feels different. Everything new in software from AI agents to edge runtimes to climate-tech dashboards starts life in a public repository where anyone can fork, remix, and improve it overnight. When you invest in that commons, you’re not just sponsoring code; you’re underwriting the world’s R&D engine.  And that’s what we want to explore in our latest podcast with an eye towards everything that makes open source what it is today.  (And yes, we also answer essential questions like: how exactly do you do a hackathon on a plane?) Meet the core contributors I’m joined by an amazing crew of rotating hosts including Cassidy Williams, Kedasha Kerr, Andrea Griffiths, and me, Abby Cabunoc Mayes — all of us long-time contributors to different parts of the open source world. Together, we’ll explore what’s exciting, challenging, and evolving in open source today. Whether it’s community building, open science, developer education, or building in public, we each bring a unique perspective to the conversation. In today’s episode, we introduce ourselves, share how we got involved in open source, and reflect on what keeps us going. We talk about the importance of creating beginner content in a world seemingly saturated with beginner developer content with Kedasha, and Cassidy talks about how overhearing a conversation as a teenager sparked her love of code.  Plus, we spotlight some of our favorite open source projects that have caught our eyes this week. Here’s a sneak peek: Anime.JS, a visually stunning JavaScript animation library that sparks creativity. Docs, a collaborative open source document editor developed by the French and German governments. CSS Zero, a no-build frontend starter kit that simplifies web development. What’s in the build? Every two weeks we’ll share a new episode with stories from maintainers, contributors, and builders across the open source ecosystem. We’ll talk about tools, standards, and the side projects that spark joy (and sometimes chaos). You’ll also hear from special guests like Jason Lengstorf, who makes TV for developers, and Keeley Hammond, a core maintainer of Electron, who’ll share their own journeys and insights. Whether you’re just getting started, or you’ve been maintaining projects for years, there’s something here for you. Coming up next: we dive into the Model Context Protocol (MCP), what it is, why it matters, and how it’s helping make AI tools more transparent and interoperable. We’ll explore how MCP builds on the long history of open standards, and what it unlocks for developers today. Don’t want to miss out? Subscribe now to stay up to date on our latest episodes. The post From first commits to big ships: Tune into our new open source podcast appeared first on The GitHub Blog. ​ Maintainers, Open Source, GitHub Podcast, open source, open source community The GitHub Blog

We often describe GitHub Copilot as an AI peer programmer, or an AI member of the team. With agentic features like coding agent, you can assign issues to Copilot, and it will diligently get to work behind the scenes, creating a proposed solution to the problem, all without even asking for a cup of coffee. Much of the initial setup for Copilot coding agent is similar to onboarding a new developer – like providing good documentation and streamlining the setup process. But since it’s AI, there are a few things that make Copilot unique as a team member (aside from it not needing caffeine). So let’s explore how this is done. We’ll start by examining the flow Copilot coding agent follows, and key strategies to ensure Copilot has the resources it needs to generate the best possible pull request. Agentic workflows in GitHub Copilot: coding agent vs. agent mode GitHub Copilot comes with two key agentic capabilities: coding agent and agent mode. Think of coding agent as an autonomous tool: you give Copilot an issue, it spins up an Actions container, iterates in the background, and comes back with a pull request (PR). Agent mode is “stay in the loop:” an interactive sidekick in the editor or on github.com that executes smaller, multi-step tasks with you in real time. Same brain, different engagement model where one’s async and pull request–oriented, while the other’s conversational and immediate. Learn more >  Inside Copilot coding agent’s workflow: From issue to ready‑to‑review pull request When you assign an issue to Copilot, it follows a set pattern: Creates a branch for the code it will create. Creates a pull request to track its work and communicate with the team. Creates a contained environment for its work (running inside GitHub Actions). Reads the issue or prompt to understand the requested task. Explores the project to determine the best approach to tackle the problem. Works iteratively toward a solution. Finalizes its work, updates the pull request, and notifies the team the pull request is ready to be reviewed. By understanding this flow, we can work to ensure Copilot is set up for success. The first two steps — creating the pull request and branch — are self-contained, and there’s no additional work for us to do to help Copilot.  So, let’s skip right to the third step — the environment — where we can configure everything Copilot might need in the environment where it’ll write the code and run tasks as it generates the pull request. Configure Copilot’s environment with GitHub Actions In keeping with the analogy of onboarding a new developer, let’s consider the environment in which GitHub Copilot — or really any developer — does its work. Before you’re able to be productive, you need specific services, libraries, and frameworks installed. Copilot is the exact same. In order for Copilot to add a new feature and run the necessary tests to ensure everything works, it needs access to all the tooling the rest of your team has. We’ll do this with a custom workflow file. Coding agent uses a container running inside GitHub Actions. If you’re not already familiar with Actions, it’s our automation platform, and is configured using YAML files, which describe the necessary tasks that need to be completed.  Actions is often used for CI/CD, so tasks like testing, deployment, etc. In this case, Actions hosts the container coding agent will use for its work. And we can take advantage of the ability to script tasks in YAML to ensure said container is set up correctly! 💡Pro tip: There’s a good chance you already have a workflow for creating an environment, which could be used for development — say like the one used when running various tests or validation scripts. You can absolutely reuse those workflows for Copilot coding agent’s environment! Example Copilot setup workflow file To do this, create a new workflow file located at .github/workflows/copilot-setup-steps.yml with a job titled copilot-setup-steps. Inside the job, you’ll list all of the steps to install the necessary requirements for the environment. Let’s say, for example, we’re building a Python app that uses SQLite. We could have a workflow file like the following, which will be run to set up the environment for Copilot: name: “Copilot Setup Steps” # Automatically run the setup steps when they are changed # Allows for streamlined validation, # and allow manual testing through the repository’s “Actions” tab on: workflow_dispatch: push: paths: – .github/workflows/copilot-setup-steps.yml pull_request: paths: – .github/workflows/copilot-setup-steps.yml jobs: # The job MUST be called `copilot-setup-steps` # otherwise it will not be picked up by Copilot. copilot-setup-steps: runs-on: ubuntu-latest # Permissions set just for the setup steps # Copilot has permissions to its branch permissions: # To allow us to clone the repo for setup contents: read # The setup steps – install Python and our dependencies steps: – name: Checkout code uses: actions/checkout@v4 – name: Set up Python uses: actions/setup-python@v4 with: python-version: “3.13” cache: “pip” – name: Install Python dependencies run: pip install -r requirements.txt – name: Install SQLite run: sudo apt update && sudo apt install sqlite3 Whenever an issue is assigned to Copilot, it will run this workflow to configure its environment so it’ll have everything it needs! 💡 Pro tip: If you know something should be done a particular way, tell Copilot! In our above example, Copilot could install the requisite services on its own. However, doing so may lead to unexpected versions or other mistakes. As I always like to joke, don’t be passive aggressive with Copilot. 😀 Set Copilot up for success with well-written issues and prompts Speaking of not being passive aggressive, now’s the perfect time to focus on the next step Copilot follows: reading the issue. This will be Copilot’s entry point into creating the pull request you’ll later review. Remember that the more clearly defined the issue, the better quality the pull request.  The best approach is to think about how you’d like to see the first issue you’re assigned on

Over the past fiscal year, our customers and partners have driven pragmatic outcomes by implementing AI-first strategies across their organizations. With AI Transformation as their framework, we helped them enrich employee experiences, reinvent customer engagement, reshape business processes and bend the curve on innovation for their people, businesses and industries. Now, we are partnering to go beyond what they thought possible to unlock even greater potential by restructuring and centralizing their business strategies with an AI-first mindset. Our cloud and AI capabilities are leading the industry, and we are committed to working closely with our customers and partners to meet their increasingly complex needs and help them become frontier AI firms. Below are several stories from the past quarter reflecting the success we have seen broadly this past year. Each showcases what we can achieve together with an approach grounded in AI business solutions, cloud and AI platforms, and security. AI is blurring the lines between personal and organizational productivity, and we are helping our customers leverage Copilots and agents combined with human ambition to create differentiation. With over one million customers in Argentina, Banco Ciudad launched a digital transformation initiative focused on AI, productivity and security. What began as a pilot program quickly grew into broad adoption with the bank implementing Microsoft 365 Copilot to improve productivity, Microsoft Copilot Studio to develop agents and Microsoft Azure to scale their AI solutions. As a result, the bank strengthened its operational resilience, empowered teams, drove sustainable growth and improved customer engagement — even in a challenging economic environment. So far, the bank has freed up 2,400 employee work hours annually with savings projected to generate $75,000 USD monthly. As one of the country’s largest financial institutions, Commonwealth Bank of Australia is harnessing AI to meet rising customer expectations by developing smarter, more secure and highly customizable banking experiences at scale. To ensure employees have the confidence and expertise to leverage AI effectively, the bank launched a structured skilling initiative to empower them with the knowledge needed to adopt AI effectively. Eighty-four percent of 10,000 Microsoft 365 Copilot users reported they would not go back to working without it; and nearly 30% of GitHub Copilot code suggestions were adopted, driving efficiency and smarter decision-making. Nonprofit Make-A-Wish is dedicated to granting hope by fulfilling wishes for children with critical illnesses across the United States. Fragmented systems, limited data access and the need to protect sensitive information were creating challenges for the organization to operate effectively, so it turned to partner Redapt for support. Make-A-Wish deployed comprehensive Microsoft cloud and AI solutions — including Azure Cloud Services, Microsoft Fabric, Microsoft 365 Copilot and Copilot Studio — to unify its data, rebuild core applications and boost staff productivity. This transformation enabled the organization to increase operational efficiency, improve collaboration across national and regional chapters and strengthen its data security to protect sensitive family data. Sheló NABEL, a wellness and beauty company based in Mexico, faced operational challenges as it expanded its network of independent entrepreneurs. With support from partner Best Practices Consulting, the company integrated Microsoft Dynamics 365 to gain real-time market insights and optimize its demand planning across more than 400 products. They also integrated Microsoft Copilot to enhance customer service and increase operational efficiency with AI. As a result, the company has achieved a 17% increase in sales, 5X faster reporting processes and real-time inventory control. Based in Saudi Arabia, technology and communications company Unifonic serves millions of people across 160 countries. As their business began to scale rapidly, they faced challenges managing a growing hybrid workforce while maintaining strong security and compliance standards. To solve this, the company deployed Microsoft 365 E5 and Microsoft 365 Copilot to automate workflows and secure data in one platform. This unified ecosystem enabled teams to reduce time spent on audits by 85%, save two hours per day on cybersecurity governance, save $250,000 USD in costs and reduce time to set up client demos by 15%. Microsoft has the leading cloud platform for AI innovation with Azure as the infrastructure, Azure AI Foundry as the applications server and Fabric as the data platform. As legal professionals face challenges with manual data entry, document generation and compliance-heavy processes, Assembly Software aimed to transform how they handle complex, time-consuming workflows. Using Azure AI Foundry, the company built NeosAI — a fully embedded generative AI solution that automates nearly every aspect of the legal workflow — from document intake to drafting and reporting. As a result, law firms using NeosAI report saving up to 25 hours per case, with document drafting time reduced from 40 hours to just minutes. This AI solution is not only boosting productivity and reducing stress for legal professionals but also enabling firms to serve more clients with greater speed and accuracy. One of the world’s oldest continuously operating companies, Husqvarna Group, faced increasing pressure to modernize its network of factories, supply chains and distribution channels to stay competitive in a rapidly evolving landscape. The company implemented a comprehensive Microsoft Azure solution — including Azure Arc, Azure IoT Operations and Azure OpenAI — to unify cloud and on-premises systems, enable real-time data insights and drive innovation across global manufacturing operations. As a result, the company achieved a 98% reduction in data deployment time, cut infrastructure imaging costs by 50% and significantly improved productivity and uptime across its connected factories. Serving over 600,000 members in the United States, Members 1st Federal Credit Union sought to modernize its data infrastructure to deliver more personalized member experiences and support data-driven decision-making. The credit union faced challenges with siloed data across more than 15 sources and legacy systems with limited analytics capabilities. With support from partner 3Cloud, the credit union combined Azure SQL, Azure Data Factory and Azure Databricks to extract, log and centralize enterprise-wide data into a cutting-edge data lakehouse. Machine learning models that took 36 hours to run can now be done in three to four hours — a reduction of about 89%. Additionally, updates within its customer relationship management software now take 30 to 40 minutes compared to

Satya Nadella, Chairman and CEO, shared the below communication with Microsoft employees this morning. As we begin a new fiscal year, I’ve been reflecting on the road we’ve traveled together and the path ahead. Before anything else, I want to speak to what’s been weighing heavily on me, and what I know many of you are thinking about: the recent job eliminations. These decisions are among the most difficult we have to make. They affect people we’ve worked alongside, learned from, and shared countless moments with—our colleagues, teammates, and friends. I want to express my sincere gratitude to those who have left. Their contributions have shaped who we are as a company, helping build the foundation we stand on today. And for that, I am deeply grateful. I also want to acknowledge the uncertainty and seeming incongruence of the times we’re in. By every objective measure, Microsoft is thriving—our market performance, strategic positioning, and growth all point up and to the right. We’re investing more in CapEx than ever before. Our overall headcount is relatively unchanged, and some of the talent and expertise in our industry and at Microsoft is being recognized and rewarded at levels never seen before. And yet, at the same time, we’ve undergone layoffs. This is the enigma of success in an industry that has no franchise value. Progress isn’t linear. It’s dynamic, sometimes dissonant, and always demanding. But it’s also a new opportunity for us to shape, lead through, and have greater impact than ever before. The success we want to achieve will be defined by our ability to go through this difficult process of “unlearning” and “learning.” It requires us to meet changing customer needs, by continuing to maintain and scale our current business, while also creating new categories with new business models and a new production function. This is inherently hard, and few companies can do both. But I have full confidence that we can, and we will once again find the resolve, courage, and clarity to deliver on our mission in this new paradigm. With that context, I want to re-ground ourselves in our why, what, and how: our mission, our priorities, and our culture. Our why: mission  What does achieving our mission look like and feel like for us as a company? When Microsoft is succeeding, the world around us must succeed too. This is why each of us chose to be here, and as a company it’s how we earn our social permission to operate. When Bill founded Microsoft, he envisioned not just a software company, but a software factory, unconstrained by any single product or category. That idea has guided us for decades. But today, it’s no longer enough. We must reimagine our mission for a new era. What does empowerment look like in the era of AI? It’s not just about building tools for specific roles or tasks. It’s about building tools that empower everyone to create their own tools. That’s the shift we are driving—from a software factory to an intelligence engine empowering every person and organization to build whatever they need to achieve. Just imagine if all 8 billion people could summon a researcher, an analyst, or a coding agent at their fingertips, not just to get information but use their expertise to get things done that benefit them. And consider how organizations, empowered with AI, could unlock entirely new levels of agility and innovation by transforming decision-making, streamlining operations, and enabling every team to achieve more together than ever before. That’s the empowerment our mission enables, creating local surplus in every company, community, and country. And that’s our opportunity ahead. Our what: priorities  To deliver on our mission, we need to stay focused on our three business priorities: security, quality, and AI transformation. We are doubling down on the fundamentals while continuing to define new frontiers in AI. Security and quality are non-negotiable. Our infrastructure and services are mission critical for the world, and without them we don’t have permission to move forward. We’ve made substantial progress across SFI, QEI, and Engineering Thrive this year, and they remain top priorities to ensure that we continuously improve our innovation velocity and our operational metrics. We will reimagine every layer of the tech stack for AI—infrastructure, to the app platform, to apps and agents. The key is to get the platform primitives right for these new workloads and for the next order of magnitude of scale. Our differentiation will come from how we bring these layers together to deliver end-to-end experiences and products, with the core ethos of a platform company that fosters ecosystem opportunity broadly. Getting both the product and platform right for the AI wave is our North Star! Our performance this past year has positioned us well. And we must move forward with the intentionality and intensity that these industry shifts demand. Our how: culture Growth mindset has served us well over the last decade—the everyday practice of being a learn-it-all, not a know-it-all. It has reshaped our culture and helped us lead with greater humility and empathy. We need to keep that. It starts with each of us as individuals and our personal drive to learn, improve, and get better every day. Professional rewards, growth, and pride in our craft will always be the prime drivers. Beyond that, we each have the opportunity to connect our personal passion and philosophy of how we derive meaning from the work we do with Microsoft’s mission to empower the world. This is what makes it all worthwhile. This platform shift is reshaping not only the products we build and the business models we operate under, but also how we are structured and how we work together every day. It might feel messy at times, but transformation always is. Teams are reorganizing. Scopes are expanding. New opportunities are everywhere. It reminds me of the early ’90s, when PCs and productivity software became standard in every home and every desk! That’s exactly where we are now with AI.

Today, the Git project released new versions to address seven security vulnerabilities that affect all prior versions of Git. Vulnerabilities in Git CVE-2025-48384 When reading a configuration value, Git will strip any trailing carriage return (CR) and line feed (LF) characters. When writing a configuration value, however, Git does not quote trailing CR characters, causing them to be lost when they are read later on. When initializing a submodule whose path contains a trailing CR character, the stripped path is used, causing the submodule to be checked out in the wrong place. If a symlink already exists between the stripped path and the submodule’s hooks directory, an attacker can execute arbitrary code through the submodule’s post-checkout hook. [source] CVE-2025-48385 When cloning a repository, Git can optionally fetch a bundle, allowing the server to offload a portion of the clone to a CDN. The Git client does not properly validate the advertised bundle(s), allowing the remote side to perform protocol injection. When a specially crafted bundle is advertised, the remote end can cause the client to write the bundle to an arbitrary location, which may lead to code execution similar to the previous CVE. [source] CVE-2025-48386 (Windows only) When cloning from an authenticated remote, Git uses a credential helper in order to authenticate the request. Git includes a handful of credential helpers, including Wincred, which uses the Windows Credential Manager to store its credentials. Wincred uses the contents of a static buffer as a unique key to store and retrieve credentials. However, it does not properly bounds check the remaining space in the buffer, leading to potential buffer overflows. [source] Vulnerabilities in Git GUI and Gitk This release resolves four new CVEs related to Gitk and Git GUI. Both tools are Tcl/Tk-based graphical interfaces used to interact with Git repositories. Gitk is focused on showing a repository’s history, whereas Git GUI focuses on making changes to existing repositories. CVE-2025-27613 (Gitk) When running Gitk in a specially crafted repository without additional command-line arguments, Gitk can write and truncate arbitrary writable files. The “Support per-file encoding” option must be enabled; however, the operation of “Show origin of this line” is affected regardless. [source] CVE-2025-27614 (Gitk) If a user is tricked into running gitk filename (where filename has a particular structure), they may run arbitrary scripts supplied by the attacker, leading to arbitrary code execution. [source] CVE-2025-46334 (Git GUI, Windows only) If a malicious repository includes an executable sh.exe, or common textconv programs (for e.g.,  astextplain, exif, or ps2ascii), path lookup on Windows may locate these executables in the working tree. If a user running Git GUI in such a repository selects either the “Git Bash” or “Browse Files” from the menu, these programs may be invoked, leading to arbitrary code execution. [source] CVE-2025-46335 (Git GUI) When a user is tricked into editing a file in a specially named directory in an untrusted repository, Git GUI can create and overwrite arbitrary writable files, similar to CVE-2025-27613. [source] Upgrade to the latest Git version The most effective way to protect against these vulnerabilities is to upgrade to Git 2.50.1, the newest release containing fixes for the aforementioned vulnerabilities. If you can’t upgrade immediately, you can reduce your risk by doing the following: Avoid running git clone with –recurse-submodules against untrusted repositories. Disable auto-fetching bundle URIs by setting the transfer.bundleURI configuration value to “false.” Avoid using the wincred credential helper on Windows. Avoid running Gitk and Git GUI in untrusted repositories. In order to protect users against attacks related to these vulnerabilities, GitHub has taken proactive steps. Specifically, we have scheduled releases of GitHub Desktop. GitHub Codespaces and GitHub Actions will update their versions of Git shortly. GitHub itself, including Enterprise Server, is unaffected by these vulnerabilities. CVE-2025-48384, CVE-2025-48385, and CVE-2025-48386 were discovered by David Leadbeater. Justin Tobler and Patrick Steinhardt provided fixes for CVEs 2025-48384 and 2025-48385 respectively. The fix for CVE-2025-48386 is joint work between Taylor Blau and Jeff King CVE-2025-46835 was found and fixed by Johannes Sixt. Mark Levedahl discovered and fixed CVE-2025-46334. Avi Halachmi discovered both CVE-2025-27613 and CVE-2025-27614, and fixed the latter. CVE-2025-27613 was fixed by Johannes Sixt. The post Git security vulnerabilities announced appeared first on The GitHub Blog. ​ Git, Open Source, security alert The GitHub Blog