DEV Community: Hector Flores

Copilot CLI Weekly: BYOK, Rubber Duck, and Direct Mode Flags

Hector Flores — Tue, 14 Apr 2026 21:51:23 +0000

The CLI Goes Fully Open: BYOK and Local Models

GitHub dropped a changelog entry on April 7 that fundamentally changes what Copilot CLI is: you can now bring your own model provider or run fully local models. No GitHub-hosted routing required. This is BYOK (bring your own key) for the terminal agent, and it's a big deal.

Here's what it means in practice: you configure environment variables pointing to Azure OpenAI, Anthropic, OpenAI, or any OpenAI-compatible endpoint, and Copilot CLI routes all inference through your provider instead of GitHub's model gateway. This works with remote services and locally running models like Ollama, vLLM, and Foundry Local.

The kicker? GitHub authentication is now optional. If you're using your own provider, you can start using Copilot CLI with just your model credentials. Sign in to GitHub later if you want features like /delegate, GitHub Code Search, and the GitHub MCP server. But the core agentic terminal experience works entirely offline and entirely on your infrastructure.

Set COPILOT_OFFLINE=true and all telemetry is disabled. Combined with a local model, this enables fully air-gapped development workflows. Run copilot help providers for setup instructions directly in the terminal. Built-in sub-agents (explore, task, code-review) automatically inherit your provider configuration.

This isn't just a feature add — it's a positioning move. Copilot CLI is no longer a GitHub-exclusive tool. It's now a provider-agnostic agentic terminal interface that happens to work great with GitHub's infrastructure but doesn't require it. If you're already paying for Azure OpenAI or running local models, you can use the same agent UX without duplicating inference costs.

I've been saying for months that context engineering is the real skill when working with AI tools. BYOK amplifies this: the CLI's agentic framework (memory, tool routing, sub-agents, MCP integration) is now decoupled from the underlying LLM provider. You control the models. The CLI controls the orchestration.

Rubber Duck: Cross-Model Reviews Close 75% of the Sonnet-Opus Gap

GitHub published a blog post on April 6 introducing Rubber Duck, an experimental feature that uses a second model from a different AI family to review the primary agent's plans and implementations. The results are striking: Claude Sonnet 4.6 + Rubber Duck running GPT-5.4 closes 74.7% of the performance gap between Sonnet and Opus on SWE-Bench Pro, a benchmark of large, difficult, real-world coding problems.

Here's how it works: when you select a Claude model from the model picker as your orchestrator, Rubber Duck uses GPT-5.4 as an independent reviewer. The job of Rubber Duck is to surface high-value concerns at critical checkpoints — details the primary agent may have missed, assumptions worth questioning, and edge cases to consider. It's not self-reflection (where the same model reviews its own work). It's cross-family review, which catches a different set of errors.

Rubber Duck activates automatically at three checkpoints:

After drafting a plan — catching suboptimal decisions before they compound downstream
After a complex implementation — reviewing edge cases in complex code
After writing tests, before executing them — catching gaps in test coverage or flawed assertions

The agent can also invoke Rubber Duck reactively if it gets stuck in a loop or can't make progress. And you can request a critique at any point — Copilot will query Rubber Duck, reason over the feedback, and show you what changed and why.

The blog post includes real examples of what Rubber Duck catches:

Architectural catch (OpenLibrary/async scheduler): Rubber Duck caught that the proposed scheduler would start and immediately exit, running zero jobs — and that even if fixed, one of the scheduled tasks was itself an infinite loop.
One-liner bug, big impact (OpenLibrary/Solr): Rubber Duck caught a loop that silently overwrote the same dict key on every iteration. Three of four Solr facet categories were being dropped from every search query, with no error thrown.
Cross-file conflict (NodeBB/email confirmation): Rubber Duck caught three files that all read from a Redis key which the new code stopped writing. The confirmation UI and cleanup paths would have been silently broken on deploy.

Rubber Duck is available today in experimental mode via the /experimental slash command. It's enabled for all Claude family models (Opus, Sonnet, Haiku) as orchestrators, paired with GPT-5.4 as the reviewer. GitHub is exploring other model families for both roles.

This is a smart implementation. The agent invokes Rubber Duck sparingly, targeting the moments where the signal is highest, without getting in the way. For the technically curious: Rubber Duck is invoked through Copilot's existing task tool — the same infrastructure used for other sub-agents. It's just another agent in the multi-agent architecture.

Combined with /fleet for parallel multi-agent execution (shipped April 1), Copilot CLI now supports both horizontal scaling (multiple agents in parallel) and vertical validation (cross-model review). That's a complete multi-agent development platform.

v1.0.23: Direct Mode Flags and UX Polish

Version 1.0.23 shipped on April 10 with one standout feature and a handful of quality-of-life fixes:

Direct Agent Mode Flags

The CLI now supports --mode, --autopilot, and --plan flags to start directly in a specific agent mode. No more launching the CLI, waiting for the prompt, then typing /agent or /autopilot every time. This is huge for scripting and automation workflows. You can now invoke the CLI programmatically with the exact mode you need:

copilot --mode agent "Refactor the auth module"
copilot --autopilot "Run all tests and fix failures"
copilot --plan "Add user preferences feature"
```
{% endraw %}
{% raw %}`

This pairs perfectly with BYOK — you can script the CLI against your own model provider with specific agent modes, no interactive input required.

### Notable Fixes

- **Agent no longer hangs on first turn when memory backend is unavailable** — previously, if the memory backend failed to connect, the agent would hang indefinitely. Now it degrades gracefully.
- **Bazel/Buck build target labels** (e.g. `{% endraw %}//package:target{% raw %}`) are no longer misidentified as file paths — if you're in a monorepo using Bazel or Buck, this was a real annoyance.
- **Ctrl+L clears the terminal screen without clearing the conversation session** — small UX win for keeping your terminal clean while maintaining context.
- **Slash command picker shows full skill descriptions and a refined scrollbar** — easier to discover and select the right command.
- **`/diff`, `/agent`, `/feedback`, `/ide`, and `/tuikit` work while the agent is running** — you can now interrupt and inspect without stopping the agent entirely.
- **Display reasoning token usage** in the per-model token breakdown when nonzero — useful for tracking extended thinking models.
- **Shell output with BEL characters no longer causes repeated terminal beeping** — if you've ever been subjected to this, you know why it matters.

## The Bottom Line

This week's releases signal where Copilot CLI is heading: **provider-agnostic orchestration with cross-model collaboration**. BYOK decouples the CLI from GitHub's model gateway. Rubber Duck adds cross-family validation. Direct mode flags make automation workflows seamless.

If you're building [custom Copilot agents](https://htek.dev/articles/top-5-mistakes-creating-custom-github-copilot-agents/), BYOK means you can test against your own model infrastructure. If you're worried about cost, BYOK lets you use models you're already paying for. If you're in an air-gapped environment, offline mode + local models is now a real option.

Rubber Duck is the kind of feature that sounds experimental but will become table stakes. Cross-model review catches a different class of errors than self-reflection. Closing 75% of the Sonnet-Opus gap is not a marginal improvement — it's a structural change in how agents reason about their own work.

The CLI is no longer just a GitHub tool. It's an agentic terminal platform that happens to integrate deeply with GitHub when you want it to. That's a much more interesting product.

Azure Weekly: Microsoft Declares AI Independence with MAI Models and Agent Framework 1.0

Hector Flores — Tue, 14 Apr 2026 21:50:45 +0000

Liquid syntax error: 'raw' tag was never closed

GitHub Weekly: Agentic Security, Remote CLI Control, and Code Quality at Scale

Hector Flores — Tue, 14 Apr 2026 21:50:19 +0000

The Week Security Went Agentic

This week GitHub made three moves that signal where platform security is heading: Dependabot alerts are now assignable to AI agents, code scanning alerts support batch fixes on PRs, and runtime context from Dynatrace can prioritize alerts based on deployed artifacts. Separately, Copilot CLI gained remote control from web and mobile, and GitHub Code Quality got search, bulk operations, and better context.

What ties these together is autonomy. Security remediation is shifting from "here's a list of vulnerabilities" to "here's an agent that can fix them" or "here's exactly which alerts matter in production." The platform is betting that the next layer of security improvement comes from orchestration, not just detection.

Dependabot Meets Agentic Remediation

Dependabot alerts are now assignable to AI coding agents—Copilot, Claude, or Codex—for vulnerabilities that need more than a version bump. When a dependency fix requires code changes across your project, you can assign the Dependabot alert to an agent instead of manually tracking down every reference.

This matters because dependency updates increasingly cascade into breaking API changes. Bumping axios from 1.x to 2.x might touch 30 files across your codebase. Instead of parsing migration guides and hunting down every instance, you assign the alert to an agent, which analyzes the breaking changes, generates the refactor plan, and opens a PR with the full migration.

Why this is important:

The vulnerability-to-fix pipeline has always been bottlenecked by human capacity. Security teams can identify thousands of issues, but developer time is finite. Agentic workflows flip that constraint—agents can parallelize remediation work across dozens of alerts simultaneously, submitting PRs for review rather than waiting in a backlog.

If you've been skeptical about AI agents doing "real work," this is the use case that converts skeptics. The scope is well-defined (fix this specific CVE), the validation is clear (tests pass, security scanner clears the alert), and the ROI is measurable (time-to-remediation).

Batch Apply Security Fixes on Pull Requests

Code scanning alerts on PRs now support bulk actions. When GitHub's code scanning surfaces multiple alerts in the Files Changed tab, you can add fixes to a batch and apply them all at once instead of clicking through alerts one at a time.

This is UX polish that compounds over time. A single PR might trigger 5-10 code scanning alerts for SQL injection risks, XSS vulnerabilities, or hardcoded secrets. Before, you'd click each alert, review the suggestion, apply it, and move to the next. Now you can triage the batch, select the valid fixes, and apply them in one operation.

The pattern I expect to see:

Agent opens a PR with new feature work
Code scanning catches 8 security issues
Human reviews the batch suggestions in 2 minutes
Applies all 8 fixes at once
PR merges

This reduces the security review bottleneck from "block every PR with issues" to "fix issues in seconds." It's not about skipping security—it's about making the fix so frictionless that blocking becomes acceptable.

Runtime Context: Prioritize Alerts That Actually Matter

GitHub now integrates runtime context from Dynatrace to prioritize Advanced Security alerts based on deployed artifacts and runtime risk in your Kubernetes environment. When you connect Dynatrace to GitHub, you see which vulnerabilities are in code paths that are actually executing in production.

This solves the alert fatigue problem from the other direction. Instead of trying to remediate every CVE in your dependency graph, you focus on the ones that are reachable, running, and exposed to traffic. A vulnerability in a dev-only dependency or dead code path gets deprioritized automatically.

Why this matters:

The shift-left movement pushed security earlier into the development cycle, but it also created noise. Scanning every commit for every possible vulnerability generates thousands of alerts—most of which don't matter. Runtime context brings shift-right observability back into the equation: "Yes, this CVE exists, but it's in a library we imported and never call."

The integration pattern here—external observability data feeding back into GitHub's priority scoring—is the template for how platforms should handle alert overload. Don't just generate more alerts. Use runtime data to filter, rank, and route them.

Remote Control for CLI Sessions

Copilot CLI now supports copilot --remote, letting you monitor and steer a running CLI session directly from GitHub on the web or mobile. You start a long-running task on your machine—database migration, test suite, deployment—and can check progress, send input, or intervene from your phone while away from your terminal.

This is the natural next step after Copilot CLI gained agentic capabilities. Agents run in the background, but you still need visibility and control. Remote sessions give you that without SSHing into your machine or opening a VNC viewer.

Use cases I expect to see:

Start a deployment script, monitor from mobile, approve production gate from phone
Kick off multi-hour integration tests before leaving office, check results on the train
Let an agent run exploratory work overnight, review the session transcript the next morning
Handoff work to a teammate by sharing a remote session link instead of screen-sharing

The public preview is available now—no additional setup beyond updating Copilot CLI. Sessions are authenticated via your GitHub account and encrypted in transit.

Code Quality Gets Search and Bulk Operations

GitHub Code Quality standard findings now support:

Search by file path: Filter findings to specific files instead of scrolling through hundreds of results
Bulk dismiss/reopen: Select multiple findings and dismiss or reopen them in bulk from the rule page
Full context per finding: See diagnostic messages and related code locations instead of just the line number

These are table-stakes features for any code analysis tool, but GitHub is iterating fast. Code Quality launched in public preview recently, and they're shipping improvements weekly. The baseline experience is "scan your default branch, surface reliability and maintainability issues, generate Copilot Autofix suggestions for each finding."

Where this is heading:

Code Quality will likely converge with code scanning and Dependabot into a unified "things wrong with your codebase" dashboard. Right now, security issues live in one tab, dependency alerts in another, and code quality findings in a third. The logical endpoint is a single prioritized work queue—sorted by runtime risk, business impact, and fix effort—that routes work to agents or humans based on complexity.

If GitHub executes on that vision, it becomes the system of record for technical debt remediation, not just vulnerability management.

Actions Workflows Limited to 50 Reruns

GitHub Actions workflows are now limited to 50 reruns. If you attempt to rerun a workflow more than 50 times, you'll get a failed check suite with an annotation indicating you hit the limit.

This is an operational guardrail, not a product change. The pattern they're preventing: flaky tests that fail 49 times before someone finally gets a green run and merges the PR. Instead of letting workflows run indefinitely, GitHub is forcing you to fix the underlying flakiness or re-trigger the workflow from scratch.

Why 50?

That's the threshold where "temporary CI infrastructure issue" becomes "your tests are fundamentally broken." One or two reruns for a flaky network call is reasonable. Fifty reruns means you have a systemic problem—race conditions, non-deterministic tests, or environment-specific failures—that rerunning won't fix.

The limit includes both manual reruns and automated retries. If you've built CI retry logic that hammers the same workflow run, you'll need to adjust it to trigger fresh workflow runs instead.

What This Week Signals

GitHub is building the infrastructure layer for agentic DevOps. Dependabot alerts route to agents. Code scanning fixes batch-apply. Runtime context filters noise. CLI sessions detach from terminals. Code Quality surfaces work queues.

None of these changes are revolutionary on their own, but the pattern is clear: shift work from "human clicks through UI to make change" to "agent operates autonomously with human approval gates." The platform is preparing for a world where most security remediation, dependency updates, and code quality fixes are handled by agents, and humans focus on architecture, prioritization, and review.

If you're building agentic workflows today, GitHub is meeting you halfway. The platform now supports assigning work to agents, applying fixes in bulk, and prioritizing based on production impact. What's left is wiring those capabilities into your specific toolchain—assigning Dependabot alerts to your internal agents, connecting your observability platform for runtime context, and orchestrating batch fixes through your review process.

The Bottom Line

This week GitHub made security remediation agentic, added remote control to CLI sessions, and improved Code Quality's usability. The underlying theme: shift repetitive security work to agents, give humans better prioritization signals, and remove friction from the fix-review-merge loop.

If you're still doing dependency updates by hand, this is the week to reconsider. The tooling is maturing fast, and the gap between "manual remediation" and "agent-assisted remediation" is widening. Not because agents are perfect—they're not—but because the platform is optimizing for agent-first workflows, and manual processes are becoming the slow path.

I Open-Sourced the AI That Runs My Household

Hector Flores — Tue, 14 Apr 2026 21:49:55 +0000

The System That Knows When to Buy Dog Food

Last Tuesday, my phone buzzed at 5:03 AM with a morning briefing: weather, three calendar events, two overdue tasks, a bill due Friday, and a reminder that the HVAC filter was overdue for replacement. I hadn't asked for any of it. By 6:15, I'd knocked out the first task — refill a prescription — and the system automatically served me the next one.

That's not a productivity app. It's not Alexa with extra steps. It's a multi-agent AI system running on GitHub Copilot CLI, communicating through Telegram, managing everything from groceries to OB appointments to content scheduling — and I just open-sourced the whole thing.

How We Got Here

It started with a single-file Telegram bridge — a few hundred lines of JavaScript that let me chat with Copilot CLI from my phone. Then I added a cron scheduler and OpenShell sandboxing. Then meal planning. Then budget tracking. Then a task coach that understood my ADD brain needed tasks served one at a time, not dumped in a list.

Three months later, I have a system with 17 specialized agents, 16 custom extensions, and 15 scheduled cron jobs running autonomously. My wife gets pregnancy reminders. My 4-year-old has a curriculum tracker. The dogs' feeding schedule is logged. The house maintenance runs on a schedule I never have to think about.

It's not a demo. It's real — it's been managing our household since January, and every correction we make gets persisted permanently so the system never repeats a mistake.

The Architecture: Agents Are Markdown, Extensions Are Code

The entire system sits in a single Git repository with a clean separation between behavior (what agents should do) and capability (what they can do).

Agents are Markdown files in .github/agents/. Each one defines an AI persona with domain expertise, decision rules, memory loading, and integration points. The finance-manager knows how to categorize expenses and track bill due dates. The dog-parent tracks feeding schedules and vet appointments. The task-coach serves tasks one at a time with momentum tracking — because dumping 30 tasks on someone with ADD is the same as giving them zero tasks.

Here's what an actual agent definition looks like — this is from the task-coach:

# Task Coach — Your Family Productivity Partner

## Identity & Personality

You are the family's productivity coach — you nudge BOTH parents.
You're energetic, encouraging, and no-nonsense. You understand that
long lists are paralyzing, context switches are expensive, and
momentum is everything.

### For {YourName} (ADD-friendly coaching):
- **One task at a time.** Never dump a list. Always serve the single next thing.
- **Celebrate wins.** Every completion gets a brief cheer before the next task.
- **Track momentum.** "You've knocked out 4 tasks today! Keep the streak going."

### For {Spouse} (gentle pregnancy-friendly coaching):
- **Ultra-short messages.** 2-3 lines max. She's carrying twins.
- **Don't nag.** If no response, wait 2+ hours. She may be resting.

That's not pseudocode — that's the actual agent file. The {YourName} and {Spouse} placeholders are what you replace when you fork the repo.

Extensions are Node.js ESM modules in .github/extensions/. They expose tools like add_expense, set_meal, telegram_send_message, and gcal_create_event. The Copilot CLI extension SDK lets you create these with the joinSession API — hooks intercept agent actions in real time.

Here's the auto-commit extension — it watches for data changes and auto-saves to Git after every tool call:

// .github/extensions/auto-commit/extension.mjs

// Tools that modify family data files
const FILE_MODIFY_TOOLS = new Set([
  "add_task", "update_task", "complete_task",
  "add_to_shopping_list", "check_off_item",
  "set_meal", "add_recipe",
  "add_expense", "add_income", "set_budget",
  "add_maintenance_task", "log_maintenance",
]);

const session = await joinSession({
  tools: [],
  hooks: {
    onPostToolUse: async (input) => {
      // After any data-modifying tool, commit and push
      if (FILE_MODIFY_TOOLS.has(input.toolName)) {
        execSync("git add -A && git commit -m 'Auto-save'", { cwd: process.cwd() });
        execSync("git push origin main", { cwd: process.cwd() });
        return { additionalContext: "[auto-commit] ✅ Committed and pushed" };
      }
    },
  },
});

Every time an agent logs an expense, completes a task, or sets a meal — the data is automatically committed to Git. No manual saves. No data loss.

The constitution (data/constitution.md) governs every agent. It defines autonomy levels, communication rules, and the core principles that make this work:

## Core Principles

1. **Act first, report after.** You are autonomous. Detect → act → notify.
   Never say "would you like me to...?" — just do it and tell them what you did.
2. **Be specific and actionable.**
   ✅ "Call MOHELA today — 90 days delinquent. Phone: 1-800-848-0979"
   ❌ "You might want to look into your MOHELA situation."
3. **Every correction is permanent.** When the family corrects you,
   persist the lesson via store_memory, standing-orders.md,
   AND copilot-instructions.md. Never repeat the same mistake.

## Autonomy Levels

| Do it immediately              | Ask first                       |
|--------------------------------|---------------------------------|
| Create calendar events & tasks | Major purchases (>$200)         |
| Add to shopping lists          | Medical decisions               |
| Relay messages between family  | Sending emails on someone's behalf |
| Log expenses, create bills     | Deleting any data               |

Every agent reads this constitution before doing anything else. It's the shared brain that keeps 17 agents behaving consistently.

Here's the actual architecture:

Telegram ↔ Copilot CLI ↔ Agents (17) + Extensions (16) + Cron (15)
              ↕
    Google Calendar / Gmail / Maps / Tasks
    Late/Zernio (social media scheduling)
    Budget database / Shopping lists / Recipes
    Family profiles / Home maintenance / Locations

What It Actually Manages

This isn't a toy. Here's what runs every day:

Morning briefings hit Telegram at 5 AM weekdays, 7 AM weekends. Weather, today's calendar, prioritized tasks, unread email summary, today's meals, upcoming bills, and health reminders — all compiled by the daily-briefing agent delegating to domain specialists.

Task coaching runs every 20 minutes. The task-coach checks what's pending, evaluates priorities and dependencies, and nudges with one task at a time. It knows to chain errands by location, front-load deadlines, and serve quick wins first for momentum. Our record was 18 tasks completed in one day — not because we were heroic, but because the system served them in the right order.

All of this is driven by cron.json — here's a slice of the actual schedule:

{
  "timezone": "America/Chicago",
  "jobs": [
    {
      "id": "morning-briefing",
      "schedule": "0 5 * * 1-5",
      "agent": "daily-briefing"
    },
    {
      "id": "task-coach-nudge",
      "schedule": "*/20 5-22 * * *",
      "agent": "task-coach"
    },
    {
      "id": "heartbeat",
      "schedule": "*/30 5-22 * * *",
      "agent": "checkin"
    },
    {
      "id": "nightly-reflection",
      "schedule": "0 21 * * *",
      "agent": "platform-manager"
    }
  ]
}

Fifteen jobs in total. Add an agent, add a cron entry — it starts running on the next cycle.

Meal planning happens Saturday mornings. The nutrition-chef manages three dietary tracks (I'm on a high-protein cut, my wife has pregnancy dietary needs, and we have a picky 4-year-old). The extension generates grocery lists cross-referenced with recipes and sends them to the shopping list.

Budget tracking is continuous. Every expense gets logged, categorized, and compared against monthly targets. The finance-manager scans Gmail for bills, creates tasks for upcoming payments, and the budget-review agent delivers a full monthly report on the 1st.

Home maintenance runs on schedules — HVAC filters, water heater flushes, pest control, appliance checks. The home-manager tracks service providers with ratings and auto-creates tasks when maintenance is due.

Health tracking handles OB appointments, medications, prescription refills, and vet visits. When my wife has an appointment, the system proactively creates prep tasks: grab insurance cards, calculate leave-by time with 15 minutes buffer based on Google Maps drive time, remind me to clean the car.

Content pipeline — this one surprised me. The content-manager agent tracks trending topics, manages an editorial calendar, coordinates with the Late/Zernio social media scheduler, and even triggers blog article creation. The blog post you're reading right now was written by a blog-writer agent that researched the repo, wrote the draft, ran parallel reviews through Claude Opus and GPT Codex, and created a PR for my review.

The Part Nobody Expects: It Learns

The most powerful feature isn't any single agent — it's the continuous learning loop.

When I told the system "don't suggest recipes — I decide what to cook," that correction got persisted to three places: cross-session memory via store_memory, behavioral rules in data/standing-orders.md, and future session instructions in .github/copilot-instructions.md. The system will never suggest a recipe again.

When my wife didn't respond to a long message asking five questions at once, I taught the system: "SHORT messages only — 2-3 lines max. ONE question at a time. She's pregnant with twins — respect her energy." That rule now governs every agent that communicates with her.

Every correction is permanent. The family is essentially training a personal AI that gets better every day. After three months, the standing orders file is dense with learned behaviors — things like "Hector's ADD brain needs tasks one at a time" and "always compute Central Time fresh from PowerShell, never trust UTC headers."

Safety: The OpenShell Layer

Running autonomous agents that can read email, create calendar events, and send messages is a trust question. I've written extensively about sandboxing agents with NVIDIA OpenShell — the project that provides kernel-level filesystem isolation, network policy enforcement, and process sandboxing for AI agents.

The Copilot Home Assistant uses the same layered safety approach I covered in the Safe OpenClaw series:

Constitution-level rules — agents know what they can and can't do autonomously
Extension-level hooks — agent hooks intercept tool calls and enforce policies
OpenShell sandboxing — kernel-level enforcement for the paranoid (recommended)
Ask-via-Telegram — high-stakes decisions route a confirmation prompt to your phone

The Telegram bridge extension itself is open source too. It started as a proof of concept and became the communication backbone of the entire system.

Here's how the bridge routes incoming Telegram messages to the right agent:

// From .github/extensions/telegram-bridge/extension.mjs
onUserPromptSubmitted: async (input) => {
  const prompt = input.prompt || "";
  if (!prompt.startsWith("[Telegram from")) return;

  // Extract sender identity from the Telegram message
  const userMatch = prompt.match(
    /\[Telegram from (.+?) \(user (\d+)\)\]: (.+)/s
  );
  if (!userMatch) return;
  const [, senderName, senderId, userMessage] = userMatch;

  // Inject context: "Pick the best agent and delegate"
  return {
    additionalContext:
      `Message from ${senderName}. ` +
      `Pick the best agent_type, launch it with the task tool, ` +
      `and the agent responds via telegram_send_message.`,
  };
},

Every Telegram message gets tagged with the sender's identity, then Copilot CLI picks the right domain agent to handle it. I text "what's for dinner?" and the nutrition-chef agent responds. I text "what tasks do I have?" and the task-coach takes over.

How to Use It

The repo is designed to be forked and customized:

Clone it: git clone https://github.com/htekdev/copilot-home-assistant
Configure Telegram: Create a bot via @BotFather, add the token to .env, and set TELEGRAM_ALLOWED_USERS with your chat ID
Personalize: Edit family profiles in data/family/, update the constitution, set your locations
Enable integrations: Add Google OAuth credentials for Calendar/Gmail/Tasks, Maps API key for drive times
Start it: Run copilot-cli — the Telegram bridge and cron scheduler start automatically via extensions

You don't need all 17 agents. Trim to what fits your family — maybe you don't have pets (remove dog-parent), don't create content (remove content-manager), or your kids are too young for curriculum tracking (remove teacher). The system is modular by design.

Want to add an agent? Copy a template from .github/agents/templates/, define its domain, decision rules, and memory file, then add a cron entry if it should run on a schedule. Agents are Markdown — not code — so anyone can create them.

Why Copilot CLI?

People ask why I didn't use LangChain, CrewAI, AutoGen, or any of the agent frameworks. The answer: the god prompt is the new monolith. Those frameworks add orchestration layers, custom runtimes, and dependency chains. Copilot CLI gives me an AI that can run shell commands, edit files, call APIs, and use the extension SDK to expose any tool I need — with zero framework overhead.

The agents are literally Markdown files. The extensions are single .mjs files. The cron scheduler is a JSON config. There's no build step, no compilation, no Docker, no Kubernetes. I edit a .md file and the agent's behavior changes instantly.

That simplicity is the whole point. This system runs my family's life — I need to be able to debug it at 2 AM when the morning briefing breaks, not trace through six layers of orchestration abstractions.

The Bottom Line

I built this because I needed it. Managing a household with a full-time engineering job, a 4-year-old, twin babies on the way, two dogs, a content pipeline, and an ADD brain that loses context every time someone says "hey, can you also..." — that's not a personal productivity problem. That's an orchestration problem.

The Copilot Home Assistant treats it like one. Seventeen agents, each owning a domain, communicating through a shared constitution, learning from corrections, and running autonomously on cron schedules. The system handles the remembering so I can focus on the doing.

Fork it. Customize it. Make it yours. And if you build something cool with it, open an issue — I'd love to see what your family's version looks like.

Your AI Terminal, In Your Pocket: Connect GitHub Copilot CLI to Telegram

Hector Flores — Sat, 11 Apr 2026 22:06:38 +0000

Why Would You Want This?

Picture this: you're walking the dog, waiting at the dentist, or three beers deep at a barbecue — and you need to check on a deployment, ask your agent to look something up, or kick off a data pipeline. You pull out your phone, open Telegram, type a message, and your GitHub Copilot CLI session on your desktop responds. The answer comes back right there in the chat.

That's what we're building. A Telegram bridge extension that turns your Copilot CLI session into a bidirectional chat — every message you send in Telegram becomes a prompt in the CLI, and every assistant response gets forwarded back. No VPN, no SSH, no remote desktop. Just Telegram.

By the end of this guide, you'll have:

📱 Bidirectional messaging — Telegram ↔ Copilot CLI
📸 Photo support — send images from Telegram for vision analysis
🎤 Voice notes — transcribed via OpenAI Whisper and forwarded as text prompts
⏰ Cron jobs — scheduled tasks that run automatically (daily briefings, heartbeat checks)
🛠️ Custom tools — telegram_send_message, telegram_send_photo, telegram_get_status

All of this runs as a Copilot CLI extension — no external servers, no Docker, no cloud functions. Just a single .mjs file in your repo.

Prerequisites

Before we start, make sure you have:

GitHub Copilot CLI installed and working (gh copilot or the standalone copilot binary)
Node.js 18+ (the extension uses fetch, AbortController, and ES modules)
A Telegram account (obviously)
~15 minutes of your time

Optional for voice note transcription:

An OpenAI API key with access to the Whisper model

Step 1: Create a Telegram Bot

Every Telegram bot starts with @BotFather. Open it in Telegram and run through the flow:

Send /newbot
Pick a display name (e.g., "Copilot CLI Bridge")
Pick a username — must end in bot (e.g., my_copilot_cli_bot)
BotFather replies with your bot token — something like 7123456789:AAH...

Save that token. You'll need it in Step 3.

💡 Tip: Also send /setdescription to give your bot a description. And /setuserpic if you want it to look professional. I use the GitHub Copilot logo.

Now open a chat with your new bot and send /start. This establishes the chat and gets it ready to receive messages.

Step 2: Build the Extension

Create the extension directory and file:

.github/
  extensions/
    telegram-bridge/
      extension.mjs

This is a single file. Let me walk through each section.

2a. Imports and Configuration


// Read config from .env file
const ENV_FILE = resolve(process.cwd(), ".env");
let TELEGRAM_TOKEN = process.env.TELEGRAM_BOT_TOKEN || "";
let TELEGRAM_CHAT_ID = process.env.TELEGRAM_CHAT_ID || "";

function parseEnvFile(filePath) {
  if (!existsSync(filePath)) return;
  const content = readFileSync(filePath, "utf-8");
  for (const line of content.split("\n")) {
    const trimmed = line.trim();
    if (!trimmed || trimmed.startsWith("#")) continue;
    const eqIndex = trimmed.indexOf("=");
    if (eqIndex === -1) continue;
    const key = trimmed.slice(0, eqIndex).trim();
    let value = trimmed.slice(eqIndex + 1).trim();
    // Strip quotes
    if (
      (value.startsWith('"') && value.endsWith('"')) ||
      (value.startsWith("'") && value.endsWith("'"))
    ) {
      value = value.slice(1, -1);
    }
    if (key === "TELEGRAM_BOT_TOKEN" && !TELEGRAM_TOKEN) TELEGRAM_TOKEN = value;
    if (key === "TELEGRAM_CHAT_ID" && !TELEGRAM_CHAT_ID) TELEGRAM_CHAT_ID = value;
  }
}

parseEnvFile(ENV_FILE);

The extension reads TELEGRAM_BOT_TOKEN from either environment variables or a .env file in your project root. TELEGRAM_CHAT_ID is optional — if set, it locks the bot to a single chat for security.

2b. Telegram API Helpers

const API_BASE = `https://api.telegram.org/bot${TELEGRAM_TOKEN}`;

async function telegramApi(method, body = {}) {
  const res = await fetch(`${API_BASE}/${method}`, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify(body),
  });
  const data = await res.json();
  if (!data.ok) throw new Error(`Telegram API error: ${data.description}`);
  return data.result;
}

This is the core of the Telegram integration. The Bot API is HTTP-based and dead simple — POST to https://api.telegram.org/bot<token>/<method> with a JSON body. No SDK needed.

2c. Message Sending With Chunking

Telegram has a 4096-character limit per message. Long assistant responses will blow right past that. Here's the sender that handles chunking and HTML formatting:

const TELEGRAM_MAX_LENGTH = 4096;

async function sendTelegramMessage(chatId, text) {
  if (!text || text.trim().length === 0) return;

  // Detect if the text already contains HTML tags
  const isHtml = /<(?:b|i|u|s|a|code|pre|em|strong)\b[^>]*>/i.test(text);

  const chunks = [];
  for (let i = 0; i < text.length; i += TELEGRAM_MAX_LENGTH) {
    chunks.push(text.slice(i, i + TELEGRAM_MAX_LENGTH));
  }

  for (const chunk of chunks) {
    try {
      if (isHtml) {
        await telegramApi("sendMessage", {
          chat_id: chatId,
          text: sanitizeTelegramHtml(chunk),
          parse_mode: "HTML",
        });
      } else {
        await telegramApi("sendMessage", {
          chat_id: chatId,
          text: markdownToTelegramHtml(chunk),
          parse_mode: "HTML",
        });
      }
    } catch {
      // Fallback to plain text if formatting fails
      const plain = chunk
        .replace(/<[^>]+>/g, "")
        .replace(/&amp;/g, "&")
        .replace(/&lt;/g, "<")
        .replace(/&gt;/g, ">");
      await telegramApi("sendMessage", { chat_id: chatId, text: plain });
    }
    // Rate limit between chunks
    if (chunks.length > 1) await sleep(150);
  }
}

The fallback is key. Telegram's HTML parser is strict — if a tag isn't closed properly, the entire message fails. By catching errors and retrying with plain text, we never lose a message.

Here are the formatting helpers:

// Telegram only supports: b, strong, i, em, u, ins, s, strike, del, a, code, pre
function sanitizeTelegramHtml(html) {
  return html
    .replace(
      /<\/?(?!b|strong|i|em|u|ins|s|strike|del|a|code|pre|\/)[a-z][^>]*>/gi,
      ""
    )
    .replace(/&amp;amp;/g, "&amp;");
}

// Convert markdown-ish text to Telegram-safe HTML
function markdownToTelegramHtml(text) {
  return text
    .replace(/&/g, "&amp;")
    .replace(/</g, "&lt;")
    .replace(/>/g, "&gt;")
    .replace(/\*\*(.+?)\*\*/g, "<b>$1</b>")
    .replace(/__(.+?)__/g, "<b>$1</b>")
    .replace(/(?<!\w)\*([^*]+?)\*(?!\w)/g, "<i>$1</i>")
    .replace(/(?<!\w)_([^_]+?)_(?!\w)/g, "<i>$1</i>")
    .replace(/`([^`]+?)`/g, "<code>$1</code>")
    .replace(/\[([^\]]+)\]\(([^)]+)\)/g, '<a href="$2">$1</a>');
}

function sleep(ms) {
  return new Promise((r) => setTimeout(r, ms));
}

2d. Long Polling Loop

This is the heart of the extension. Long polling is Telegram's recommended way to receive messages without a webhook server:

let running = false;
let pollOffset = 0;
let activeChatId = TELEGRAM_CHAT_ID || null;

async function skipOldUpdates() {
  try {
    const result = await telegramApi("getUpdates", {
      offset: -1,
      limit: 1,
      timeout: 0,
    });
    if (result.length > 0) {
      pollOffset = result[0].update_id + 1;
    }
  } catch {
    /* start from 0 */
  }
}

async function pollLoop(session) {
  running = true;
  await sleep(2000); // Let any previous instance release
  await skipOldUpdates();

  try {
    const me = await telegramApi("getMe");
    await session.log(
      `🤖 Telegram bot connected: @${me.username} (${me.first_name})`
    );
  } catch (err) {
    await session.log(`⚠️ Could not verify bot: ${err.message}`, {
      level: "warning",
    });
  }

  await session.log("📡 Telegram long polling started");

  while (running) {
    try {
      const res = await fetch(`${API_BASE}/getUpdates`, {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({
          offset: pollOffset,
          timeout: 10,
          allowed_updates: ["message"],
        }),
      });
      const data = await res.json();
      if (!data.ok) {
        await sleep(5000);
        continue;
      }

      for (const update of data.result) {
        pollOffset = update.update_id + 1;
        if (!update.message) continue;

        const msg = update.message;
        const chatId = String(msg.chat.id);
        const from = msg.from?.first_name || msg.from?.username || "Unknown";

        // Security: restrict to configured chat
        if (TELEGRAM_CHAT_ID && chatId !== TELEGRAM_CHAT_ID) {
          await sendTelegramMessage(
            chatId,
            "⛔ Unauthorized. This bot is locked to a specific chat."
          );
          continue;
        }

        activeChatId = chatId;

        // Handle /start, /status, /help commands
        if (msg.text === "/start") {
          await sendTelegramMessage(
            chatId,
            `✅ Connected! Your chat ID is: ${chatId}\n\n` +
              `Send any message to forward it to your Copilot CLI session.`
          );
          continue;
        }

        if (msg.text === "/status") {
          await sendTelegramMessage(
            chatId,
            `📡 Bridge active\n• Chat: ${chatId}\n• Polling: ${running}`
          );
          continue;
        }

        // Forward text to session
        if (msg.text) {
          await session.log(`💬 [Telegram] ${from}: ${msg.text.slice(0, 80)}`);
          session
            .send({
              prompt: `[Telegram from ${from}]: ${msg.text}`,
              mode: "immediate",
            })
            .catch(() => {});
          continue;
        }
      }
    } catch (err) {
      if (err.name === "AbortError") break;
      await session.log(`⚠️ Poll error: ${err.message}`, {
        level: "warning",
      });
      await sleep(3000);
    }
  }
}

A few design decisions worth calling out:

skipOldUpdates() — On startup, we skip any messages that arrived while the bot was offline. Without this, you'd get a flood of old messages replayed.
mode: "immediate" — This tells the session to handle the prompt right now, even if it's in the middle of something. The alternative is "enqueue", which queues it for later.
timeout: 10 in getUpdates — Telegram holds the connection open for 10 seconds, then returns empty if no messages arrived. This is long polling: low latency, low CPU, no webhook infrastructure needed.

Step 3: Configure Your Environment

Create a .env file in your project root:

TELEGRAM_BOT_TOKEN=7123456789:AAH_your_token_here

That's the minimum. Optionally, lock the bot to your chat:

TELEGRAM_BOT_TOKEN=7123456789:AAH_your_token_here
TELEGRAM_CHAT_ID=123456789

💡 How to get your chat ID: Send /start to your bot, then check the Telegram API response — it contains your chat.id. Or just start the extension and look at the logs when you send a message.

Important: Add .env to your .gitignore:

echo ".env" >> .gitignore

Step 4: Register Tools

The extension exposes three tools to the Copilot CLI session. These go in the joinSession() call:

const session = await joinSession({
  hooks: {
    onSessionStart: async () => {
      if (!TELEGRAM_TOKEN) {
        return {
          additionalContext:
            "[telegram-bridge] Not active — set TELEGRAM_BOT_TOKEN in .env.",
        };
      }
      return {
        additionalContext:
          "[telegram-bridge] Telegram bridge is ACTIVE. " +
          "Incoming messages appear as prompts. " +
          "Responses are auto-forwarded to Telegram.",
      };
    },
  },

  tools: [
    {
      name: "telegram_send_message",
      description:
        "Send an explicit message to the connected Telegram chat.",
      parameters: {
        type: "object",
        properties: {
          message: {
            type: "string",
            description: "The message text to send to Telegram",
          },
          chat_id: {
            type: "string",
            description: "Optional: specific chat ID. Defaults to active chat.",
          },
        },
        required: ["message"],
      },
      handler: async (args) => {
        const targetChat = args.chat_id || activeChatId;
        if (!targetChat)
          return "No active Telegram chat. Message the bot first.";
        await sendTelegramMessage(targetChat, args.message);
        return `Message sent to chat ${targetChat}`;
      },
    },

    {
      name: "telegram_send_photo",
      description:
        "Send a photo to the connected Telegram chat. " +
        "Accepts a local file path or URL.",
      parameters: {
        type: "object",
        properties: {
          photo: {
            type: "string",
            description: "Path to local image or URL",
          },
          caption: {
            type: "string",
            description: "Optional caption (max 1024 chars)",
          },
          chat_id: {
            type: "string",
            description: "Optional: specific chat ID",
          },
        },
        required: ["photo"],
      },
      handler: async (args) => {
        const targetChat = args.chat_id || activeChatId;
        if (!targetChat) return "No active Telegram chat.";

        const isUrl =
          args.photo.startsWith("http://") || args.photo.startsWith("https://");
        if (isUrl) {
          const body = { chat_id: targetChat, photo: args.photo };
          if (args.caption) body.caption = args.caption;
          await telegramApi("sendPhoto", body);
        } else {
          const fileData = readFileSync(args.photo);
          const formData = new FormData();
          formData.append("chat_id", targetChat);
          formData.append("photo", new Blob([fileData]), basename(args.photo));
          if (args.caption) formData.append("caption", args.caption);
          const res = await fetch(`${API_BASE}/sendPhoto`, {
            method: "POST",
            body: formData,
          });
          const data = await res.json();
          if (!data.ok) throw new Error(data.description);
        }
        return `Photo sent to chat ${targetChat}`;
      },
    },

    {
      name: "telegram_get_status",
      description: "Check the Telegram bridge connection status.",
      parameters: { type: "object", properties: {} },
      handler: async () =>
        JSON.stringify(
          {
            configured: !!TELEGRAM_TOKEN,
            polling: running,
            activeChatId: activeChatId || "none",
          },
          null,
          2
        ),
    },
  ],
});

These tools let the agent proactively send content to Telegram — status updates, generated reports, photos, anything. Without them, the only messages going to Telegram would be auto-forwarded assistant responses.

Step 5: Auto-Forward Responses

This is the magic that makes it feel like a real chat. After joinSession(), subscribe to the session's event stream:

session.on("assistant.message", async (event) => {
  if (!activeChatId || !TELEGRAM_TOKEN || !running) return;

  const content = event.data.content;
  if (!content || content.trim().length === 0) return;

  try {
    const chunks = [];
    for (let i = 0; i < content.length; i += TELEGRAM_MAX_LENGTH) {
      chunks.push(content.slice(i, i + TELEGRAM_MAX_LENGTH));
    }
    for (const chunk of chunks) {
      try {
        await telegramApi("sendMessage", {
          chat_id: activeChatId,
          text: chunk,
          parse_mode: "Markdown",
        });
      } catch {
        // Fallback to plain text
        await telegramApi("sendMessage", {
          chat_id: activeChatId,
          text: chunk,
        });
      }
      if (chunks.length > 1) await sleep(150);
    }
  } catch (err) {
    await session.log(`⚠️ Forward failed: ${err.message}`, {
      level: "warning",
    });
  }
});

Every time the assistant finishes a response, it gets forwarded to Telegram. We use parse_mode: "Markdown" for auto-forwarded messages because assistant responses usually contain markdown. If parsing fails (unclosed backticks, weird formatting), the fallback sends plain text.

Start Polling on Load

Finally, kick off the polling loop:

if (TELEGRAM_TOKEN) {
  pollLoop(session).catch(async (err) => {
    await session.log(`❌ Polling crashed: ${err.message}`, {
      level: "error",
    });
  });
} else {
  await session.log(
    "⚠️ TELEGRAM_BOT_TOKEN not found — bridge disabled",
    { level: "warning" }
  );
}

Step 6: Test It

Start a Copilot CLI session in your project directory:

   copilot

Look for the startup logs:

   🤖 Telegram bot connected: @my_copilot_cli_bot (Copilot CLI Bridge)
   📡 Telegram long polling started — waiting for messages

Open Telegram and send your bot a message:

   What time is it?

You should see:
- In the CLI: 💬 [Telegram] Hector: What time is it?
- In Telegram: the assistant's response appears
Test the tools — ask the CLI directly:

   Send a message to Telegram saying "Hello from the CLI!"

The agent will call telegram_send_message and you'll see it in Telegram.

That's it. You now have a bidirectional Telegram ↔ Copilot CLI bridge.

Bonus: Voice Notes With Whisper

Want to send voice notes from Telegram and have them transcribed into text prompts? Add this to the polling loop's message handler, right after the text message handler:

// Handle voice notes
if (msg.voice || msg.audio) {
  const voiceObj = msg.voice || msg.audio;
  await session.log(`🎤 [Telegram] ${from}: voice (${voiceObj.duration}s)`);

  setTimeout(async () => {
    try {
      const openaiKey = process.env.OPENAI_API_KEY;
      if (!openaiKey) {
        await sendTelegramMessage(chatId, "⚠️ No OpenAI key for transcription.");
        return;
      }

      // Download voice file from Telegram
      const fileInfo = await telegramApi("getFile", {
        file_id: voiceObj.file_id,
      });
      const fileUrl =
        `https://api.telegram.org/file/bot${TELEGRAM_TOKEN}/${fileInfo.file_path}`;
      const audioRes = await fetch(fileUrl);
      const audioBuffer = Buffer.from(await audioRes.arrayBuffer());

      // Build multipart form for Whisper API
      const boundary = "----WhisperBoundary" + Date.now();
      const ext = (fileInfo.file_path || "voice.ogg").split(".").pop();
      const filename = `voice.${ext}`;
      const mimeMap = {
        ogg: "audio/ogg",
        oga: "audio/ogg",
        mp3: "audio/mpeg",
        m4a: "audio/mp4",
        wav: "audio/wav",
      };
      const mime = mimeMap[ext] || "audio/ogg";

      const parts = [
        `--${boundary}\r\nContent-Disposition: form-data; name="file"; filename="${filename}"\r\nContent-Type: ${mime}\r\n\r\n`,
        audioBuffer,
        `\r\n--${boundary}\r\nContent-Disposition: form-data; name="model"\r\n\r\nwhisper-1\r\n--${boundary}--\r\n`,
      ];
      const bodyBuffer = Buffer.concat([
        Buffer.from(parts[0]),
        parts[1],
        Buffer.from(parts[2]),
      ]);

      const whisperRes = await fetch(
        "https://api.openai.com/v1/audio/transcriptions",
        {
          method: "POST",
          headers: {
            Authorization: `Bearer ${openaiKey}`,
            "Content-Type": `multipart/form-data; boundary=${boundary}`,
          },
          body: bodyBuffer,
        }
      );

      if (!whisperRes.ok) throw new Error(`Whisper ${whisperRes.status}`);
      const result = await whisperRes.json();
      const transcript = result.text || "(empty)";

      await session.log(`🎤 Transcribed: ${transcript.slice(0, 100)}...`);
      await session.send({
        prompt: `[Telegram from ${from}]: ${transcript}`,
        mode: "immediate",
      });
    } catch (err) {
      await sendTelegramMessage(
        chatId,
        `⚠️ Transcription failed: ${err.message.slice(0, 100)}`
      );
    }
  }, 0);
  continue;
}

Add OPENAI_API_KEY to your .env:

OPENAI_API_KEY=sk-...

Now you can hold down the mic button in Telegram, speak your prompt, and it gets transcribed and fed to the CLI session as text. I use this constantly when I'm on the move.

Bonus: Add Cron Jobs

Once you have Telegram working, the natural next question is: "Can the agent do things on a schedule?" Yes. Let's build a cron scheduler extension.

The Cron Scheduler Extension

Create .github/extensions/cron-scheduler/extension.mjs:


// ---- Cron parser (5-field: min hour dom month dow) ----
function parseCronField(field, min, max) {
  const values = new Set();
  for (const part of field.split(",")) {
    if (part === "*") {
      for (let i = min; i <= max; i++) values.add(i);
      continue;
    }
    const stepMatch = part.match(/^(.+)\/(\d+)$/);
    if (stepMatch) {
      const step = parseInt(stepMatch[2], 10);
      let start = min, end = max;
      if (stepMatch[1] !== "*") {
        const r = stepMatch[1].split("-");
        start = parseInt(r[0], 10);
        if (r.length === 2) end = parseInt(r[1], 10);
      }
      for (let i = start; i <= end; i += step) values.add(i);
      continue;
    }
    const rangeMatch = part.match(/^(\d+)-(\d+)$/);
    if (rangeMatch) {
      for (let i = parseInt(rangeMatch[1]); i <= parseInt(rangeMatch[2]); i++)
        values.add(i);
      continue;
    }
    values.add(parseInt(part, 10));
  }
  return values;
}

function parseCron(expr) {
  const f = expr.trim().split(/\s+/);
  if (f.length !== 5) throw new Error(`Invalid cron: "${expr}"`);
  return {
    minutes: parseCronField(f[0], 0, 59),
    hours: parseCronField(f[1], 0, 23),
    daysOfMonth: parseCronField(f[2], 1, 31),
    months: parseCronField(f[3], 1, 12),
    daysOfWeek: parseCronField(f[4], 0, 6),
  };
}

function cronMatches(parsed, date) {
  return (
    parsed.minutes.has(date.getMinutes()) &&
    parsed.hours.has(date.getHours()) &&
    parsed.daysOfMonth.has(date.getDate()) &&
    parsed.months.has(date.getMonth() + 1) &&
    parsed.daysOfWeek.has(date.getDay())
  );
}

function nowInTimezone(tz) {
  return new Date(new Date().toLocaleString("en-US", { timeZone: tz }));
}

// ---- Config ----
const CRON_FILE = resolve(process.cwd(), "cron.json");
const CRON_ENABLED =
  process.env.CRON_ENABLED === "true" || process.env.CRON_ENABLED === "1";
let config = { timezone: "UTC", jobs: [] };
let parsedJobs = [];

function loadConfig() {
  if (!CRON_ENABLED || !existsSync(CRON_FILE)) return;
  try {
    config = JSON.parse(readFileSync(CRON_FILE, "utf-8"));
    config.timezone = config.timezone || "UTC";
    parsedJobs = (config.jobs || [])
      .filter((j) => j.enabled !== false)
      .map((j) => ({ ...j, parsed: parseCron(j.schedule) }));
  } catch {
    parsedJobs = [];
  }
}

loadConfig();
if (existsSync(CRON_FILE)) {
  watchFile(CRON_FILE, { interval: 5000 }, () => loadConfig());
}

// ---- Scheduler ----
const lastFired = new Map();
function minuteKey(d) {
  return `${d.getFullYear()}-${d.getMonth()}-${d.getDate()}-${d.getHours()}-${d.getMinutes()}`;
}

async function checkSchedule(session) {
  if (parsedJobs.length === 0) return;
  const now = nowInTimezone(config.timezone);
  const mk = minuteKey(now);

  for (const job of parsedJobs) {
    if (!cronMatches(job.parsed, now)) continue;
    const key = `${job.id}:${mk}`;
    if (lastFired.has(key)) continue;
    lastFired.set(key, true);

    await session.log(`⏰ [cron] Running: ${job.id}`);
    await session.send({
      prompt: `[Scheduled Task: ${job.id}] ${job.prompt}`,
      mode: "enqueue",
    });
  }
}

// ---- Session ----
const session = await joinSession({
  hooks: {
    onSessionStart: async () => ({
      additionalContext: CRON_ENABLED
        ? `[cron] ${parsedJobs.length} job(s) active (${config.timezone})`
        : "[cron] Disabled — set CRON_ENABLED=true",
    }),
  },
  tools: [
    {
      name: "cron_list_jobs",
      description: "List all configured cron jobs.",
      parameters: { type: "object", properties: {} },
      handler: async () => {
        loadConfig();
        if (config.jobs.length === 0) return "No cron jobs configured.";
        return config.jobs
          .map((j) => `• ${j.id}: ${j.schedule} [${j.enabled === false ? "off" : "on"}]`)
          .join("\n");
      },
    },
  ],
});

// Start scheduler loop
if (CRON_ENABLED && parsedJobs.length > 0) {
  setInterval(() => checkSchedule(session).catch(() => {}), 60_000);
  checkSchedule(session).catch(() => {});
  await session.log(`⏰ Cron active: ${parsedJobs.length} job(s)`);
}

The cron.json File

Create cron.json in your project root:

{
  "timezone": "America/Chicago",
  "jobs": [
    {
      "id": "daily-briefing",
      "schedule": "0 6 * * 1-5",
      "enabled": true,
      "prompt": "Give me a morning briefing: check my calendar for today, any urgent emails, and top priorities."
    },
    {
      "id": "heartbeat",
      "schedule": "*/20 6-22 * * 1-5",
      "enabled": true,
      "prompt": "Quick scan: any new emails or Teams messages in the last 20 minutes that need attention?"
    }
  ]
}

The cron syntax is standard 5-field: minute hour day-of-month month day-of-week.

Schedule	Meaning
`0 6 * * 1-5`	6:00 AM, Monday–Friday
`/20 6-22 * 1-5`	Every 20 min, 6 AM–10 PM, weekdays
`0 9,17 * * *`	9 AM and 5 PM, every day
`30 8 1 * *`	8:30 AM on the 1st of each month

Enable the scheduler in your .env:

CRON_ENABLED=true

Agent-Based Cron Jobs

For complex recurring tasks, you can point a cron job at an agent file instead of an inline prompt. Agent files live in .github/agents/ and contain detailed instructions:

{
  "timezone": "America/Chicago",
  "jobs": [
    {
      "id": "heartbeat",
      "schedule": "*/20 6-22 * * 1-5",
      "enabled": true,
      "agent": "heartbeat"
    }
  ]
}

When the agent field is present instead of prompt, the scheduler reads .github/agents/heartbeat.agent.md and launches a background agent with those instructions. Here's a simplified example:

---
name: heartbeat
description: "Scan recent activity and take action"
tools:
  - telegram_send_message
  - list_actions
  - add_action
---

# Heartbeat Agent

You are an autonomous assistant running a scheduled check.

## Phase 1: Scan Inbound Activity
- Check emails received in the last 20 minutes
- Check Teams messages received in the last 20 minutes
- If nothing new: stay silent, return "No activity."

## Phase 2: Act
- For each message, classify: needs response? needs action item?
- Auto-reply to simple acknowledgments
- Escalate complex decisions to Telegram

## Phase 3: Housekeeping
- Create action items for follow-ups
- Update existing items if a message resolves one

This is powerful. Your Copilot CLI session becomes an autonomous assistant that checks your communications, takes routine actions, and escalates to your phone via Telegram when it needs your judgment.

What's Next?

Once you have the bridge and cron running, the possibilities open up:

Watch lists — Track specific threads or customers and get notified when they reply
Auto-reply rules — Let the agent handle routine messages with predefined response templates
Custom agents — Build specialized agents (daily report, code reviewer, data pipeline) and schedule them via cron
Photo analysis — Send screenshots from your phone and ask the agent to analyze them (the extension already supports photo forwarding via vision)
Multi-device — Add the same bot to a Telegram group so your team can interact with the agent

The full production version of this extension (with typing indicators, conflict handling, photo uploads, and the standalone bridge mode toggle) is about 750 lines. What I've shown here is the core — everything you need to get started. Once it's working, you'll find yourself reaching for your phone to talk to your CLI more than you'd expect.

The code runs locally on your machine. Your messages go through Telegram's servers (encrypted in transit), but the agent, the tools, and all your data stay on your box. No cloud functions, no middleware, no third-party agent platforms. Just Telegram's Bot API, the Copilot CLI extension SDK, and a .env file.

That's the whole thing. Go build it.

VS Code Weekly: Agentic Dev Gets Real with 1.115

Hector Flores — Wed, 08 Apr 2026 14:14:20 +0000

Microsoft Just Shipped Twice in One Week

VS Code 1.115 dropped this morning, hot on the heels of 1.114 last Wednesday. This rapid back-to-back shipping pace is wild, but what's more interesting is what they're shipping: the team is racing to make agentic workflows feel native, not bolted on.

Let me break down what actually matters from these two releases, because there's a clear story here about where Microsoft thinks AI-assisted development is going.

The #codebase Overhaul: Semantic Search Gets Serious

The biggest change in 1.114 is one that most people will barely notice — but it's critical. Microsoft ripped out all the complexity around workspace indexing and made #codebase purely semantic.

Previously, the #codebase tool in Copilot Chat would fall back to fuzzy text searches when semantic indexes weren't available. There were "local indexes" (a few thousand files, not always semantic) and "remote indexes" (millions of files, shared across teams). You had to manage this mess yourself.

Now? There's one state: indexed or not indexed. No more local vs. remote. No more half-semantic fallbacks. If your codebase is indexed, #codebase runs semantic searches. If it's not, agents use other methods (text, grep, symbols).

Why this matters: Agentic workflows fail when tools return inconsistent results. If #codebase sometimes returns semantic matches and sometimes returns dumb fuzzy results, agents can't build reliable prompts around it. By making the behavior predictable, Microsoft is giving agents a tool they can actually use correctly.

The tradeoff: Large codebases without GitHub repos might not be indexable yet. Microsoft is rolling out support slowly. But in my testing, agents still get decent results using fallback methods for non-indexed workspaces.

Bottom line: This is what "agentic-first design" looks like. Not flashy, but crucial for making agents trustworthy.

Chat UX Polish: The Little Things Add Up

1.114 also shipped a handful of chat refinements that sound minor but are surprisingly high-impact:

Copy Final Response

The new Copy Final Response command strips out all the agent's internal thinking, tool calls, and noise — you just get the final Markdown output. This is huge for sharing Copilot's work with teammates who don't need to see the sausage being made.

Before this, copying a chat response meant pasting a wall of [Running tool: workspace_search] and [Thinking...] garbage. Now you get clean Markdown you can drop into a PR comment or Slack thread.

Video in the Image Carousel

The image carousel (introduced in 1.113) now supports videos. You can preview videos from chat attachments or the Explorer context menu with playback controls and thumbnail navigation.

This isn't revolutionary, but it's another sign that VS Code is becoming a full IDE for multimodal content — not just code and images, but video, audio, and whatever comes next.

Troubleshoot Previous Sessions

The /troubleshoot skill can now analyze previous chat sessions using #session references. This is critical for debugging why custom instructions were ignored or why responses were slow — you can investigate after the fact without reproducing the issue.

From an enterprise perspective, this is a huge win for debugging Copilot customization issues at scale.

VS Code 1.115: Agent Host Protocol Goes Hard

1.115, which landed this morning, doubles down on the "agentic dev" bet with a cluster of Agent Host Protocol improvements. If you're not familiar, the Agent Host Protocol is VS Code's framework for running AI agents inside the editor with structured access to tools, terminals, and context.

Here's what shipped:

Background Terminal Upgrades

Background terminals now automatically notify agents when commands complete, including the exit code and output. Prompts for input are also detected and surfaced.

This fixes a longstanding issue: when agents ran commands in the background using run_in_terminal with a timeout, terminals would become read-only and lose state. The new send_to_terminal tool sends commands with user confirmation and preserves terminal interactivity.

I've hit this exact problem dozens of times. Agents would fire off npm install in the background and then have no idea if it succeeded or failed. Now they get clean signal.

Agent Session File Edit Tracking

VS Code now tracks and restores file edits in agent sessions, delivering diffs, undo/redo, and state restoration for customizations made during a session.

This means agents can make exploratory changes to your codebase, revert them cleanly, and track exactly what they modified. It's the foundation for workflows where agents iterate on solutions without leaving a mess behind.

Browser Tab Tracking for Agents

Chat can now track and link to browser tabs that were opened or interacted with during a session. Agents can reference open web pages in their context.

Imagine an agent debugging a web app: it opens the page in VS Code's integrated browser, inspects the rendered output, and references specific elements in its next prompt. That's the workflow this enables.

SSH Remote Connection Automation

VS Code can now connect to remote machines over SSH and automatically install the CLI and start it in agent host mode. This is a major quality-of-life improvement for teams running agents on remote dev boxes or cloud workstations.

Other Notable Bits

Test coverage in the minimap: You can now see coverage indicators directly in the minimap (finally).
Terminal file paste: Drag-and-drop images or files into the terminal, or paste with Ctrl+V. Surprisingly useful for SSH workflows.
Pinch-to-zoom in integrated browser: Mac users can now pinch-to-zoom in the integrated browser. Small, but polished.

TypeScript 6.0 Ships (And 7.0 Is Coming)

Buried in 1.114 is the TypeScript 6.0 update. This major release includes important cleanup work and deprecates older options in preparation for the TypeScript 7.0 rewrite.

If you're maintaining TypeScript tooling or extensions, pay attention: TypeScript 7.0 is a ground-up rewrite with breaking changes. The team is using 6.0 as a transition release to surface deprecation warnings early.

Read the TypeScript 6.0 release notes for the full list of deprecated options.

What This Week Signals

Microsoft is shipping two things in parallel:

Agent infrastructure (background terminals, session tracking, file diffs, browser context)
Agent UX polish (copy final response, troubleshoot sessions, simplified indexing)

The pattern is clear: they're not just adding features to Copilot Chat. They're building a platform for agentic workflows where agents have structured, reliable access to tools, and the UX is designed around iterative, multi-step problem-solving.

This rapid back-to-back pace helps here. Small, focused releases let them experiment with agent workflows in production without shipping half-baked features in monthly milestones.

The Bottom Line

If you're building on VS Code's extension APIs or Copilot Chat, these two releases are a signal: bet on agents having more capabilities, not fewer. The team is moving fast to give agents access to terminals, file systems, browsers, and remote environments with proper state management and undo.

For individual developers, the takeaway is simpler: keep your VS Code updated. These rapid incremental releases are stable, and the improvements compound fast. The #codebase changes alone are worth updating for if you work in large repos.

We're not just getting better chat responses. We're getting a fundamentally different development environment where agents are first-class collaborators with structured access to your tools. That's the bet Microsoft is making, and these two releases are proof they're serious about it.

Visual Studio Weekly: Custom Copilot Agents Are Here

Hector Flores — Wed, 08 Apr 2026 14:13:42 +0000

Visual Studio's March 2026 update dropped last week, and it's the most significant Copilot extensibility release I've seen in the IDE. Custom agents, live profiling during debugging, and enterprise MCP governance are all here. If you've been waiting for AI tooling that actually fits your workflow instead of forcing you into a generic assistant box, this is the update.

Custom Agents: Build Copilot for Your Codebase

The headline feature is custom agents. You can now define specialized Copilot agents as .agent.md files in your repository. Drop them in .github/agents/ and they appear in the agent picker, ready to use with full access to workspace awareness, code understanding, tools, and MCP connections.

This is what AI extensibility should look like. Instead of prompting a general-purpose assistant to "follow our coding standards" every single time, you define an agent that knows your standards, can run your build pipeline, query your internal docs, and enforce your team's conventions automatically.

From the Visual Studio blog:

Want Copilot to follow your team's coding standards, run your build pipeline, or query your internal docs? Custom agents make that possible.

The implementation is straightforward. Each agent is a markdown file with instructions, tool access, and optional MCP server connections. If you don't specify a model, it uses whatever you've selected in the model picker. The awesome-copilot repo has community-contributed examples you can use as starting points, though you'll need to verify tool names since they vary across GitHub Copilot platforms.

This bridges the gap between generic AI assistants and the specialized workflows enterprises actually need. It's what I've been calling for in my article on choosing the right AI SDK — AI tooling that adapts to your context instead of forcing you to adapt to it.

Agent Skills: Reusable Instruction Sets

Alongside custom agents, Visual Studio now supports agent skills — reusable instruction sets that teach agents how to perform specific tasks. Skills live in .github/skills/ in your repo or ~/.copilot/skills/ in your user profile. Each skill is a directory with a SKILL.md file following the Agent Skills specification.

When a skill is activated, it appears in the chat so you know it's being applied. The awesome-copilot repo has community-shared skills you can pull in immediately.

The difference between agents and skills: agents are complete AI personalities with full tool access and model selection. Skills are modular instruction sets that any agent can use. Think of skills as teaching Copilot a technique, while agents are purpose-built specialists.

Find_symbol Tool: Language-Aware Navigation

Copilot's agent mode now includes a find_symbol tool that gives agents language-aware symbol navigation. Instead of searching for text patterns, the agent can find all references to a symbol, access type metadata, understand declarations and scope, and navigate your code using actual language services.

This is the difference between "find all occurrences of getUserData" and "find all call sites of this method, understand its signature, and refactor every usage correctly." Supported languages include C++, C#, Razor, TypeScript, and any language with a supported LSP extension.

For best results, use AI models that support tool-calling. Check out Microsoft's AI model comparison for details.

Live Profiling During Debugging

Performance optimization used to happen after you wrote the code. Now it happens while you're debugging it.

Visual Studio's new PerfTips feature integrates with the Profiler Agent to show execution time and performance signals inline as you step through code. When you spot a slow line, click the PerfTip and ask Copilot for optimization suggestions on the spot. The Profiler Agent captures elapsed time, CPU usage, and memory behavior automatically, so Copilot's suggestions are based on actual runtime data.

There's also a new "Profile with Copilot" command in Test Explorer. Right-click a test, select "Profile with Copilot," and the Profiling Agent runs the test, analyzes CPU and instrumentation data, and delivers actionable performance insights. No profiler configuration required.

This keeps optimization in your regular debugging workflow instead of being a separate investigation phase. I've lost track of how many times I've needed to reproduce a perf issue just to profile it properly — this eliminates that friction.

Security: Fix Vulnerabilities from Solution Explorer

NuGet package vulnerabilities now surface a "Fix with GitHub Copilot" link directly in Solution Explorer. Click through, and Copilot analyzes the vulnerability, recommends targeted dependency updates, and implements them without disrupting your workflow.

No more manual vulnerability research or hunting down compatible package versions. You address security issues the moment they're discovered.

Enterprise MCP Governance

MCP server usage in Visual Studio now respects allowlist policies set through GitHub. Admins can specify which MCP servers are allowed within their organizations. When an allowlist is configured, only approved servers can connect. If you try to use an unauthorized server, you get an error explaining the restriction.

This is critical for enterprises that need to control which external services process their code. MCP servers are powerful — they can query APIs, access databases, read documentation systems — but that power needs governance. This update provides it.

If you're building custom agents with MCP connections, this is the compliance layer you need. I covered context engineering as the key to AI-assisted development, and enterprise MCP governance is the security model that makes context engineering viable at scale.

Bookmark Studio: A New Way to Navigate Code

Separately, Mads Kristensen released Bookmark Studio, an experimental extension that overhauls Visual Studio's bookmark feature with slot-based navigation, a dedicated manager tool window, labels, colors, folders, and the ability to export bookmarks as plain text, Markdown, or CSV.

Bookmarks can be assigned to slots 1-9 and jumped to with shortcuts like Alt+Shift+1 through Alt+Shift+9. Bookmark Studio also tracks bookmarks as text moves during editing, so they stay attached to the relevant code instead of drifting.

This isn't part of the core Visual Studio release, but it's worth checking out if you navigate large codebases frequently. You can download it from the Visual Studio Marketplace.

What This Signals

Visual Studio is betting hard on AI extensibility. Custom agents, agent skills, and enterprise MCP governance are all infrastructure for building specialized AI tooling that fits your workflow. Microsoft isn't trying to build one AI assistant that does everything — they're building a platform so you can build the assistants you need.

This aligns with the broader shift toward multi-agent systems I've been tracking. GitHub's Copilot SDK launched recently, and now Visual Studio has the extensibility layer to make custom agents practical for enterprise teams.

If you're building .NET, C++, or enterprise applications in Visual Studio, this update is worth your time. Download Visual Studio 2026 Preview and start building custom agents for your team's workflow.

The era of one-size-fits-all AI assistants is over. Custom agents are here.

GitHub Weekly: Copilot SDK Goes Public, Cloud Agent Breaks Free

Hector Flores — Wed, 08 Apr 2026 14:13:39 +0000

The Week GitHub Stopped Playing Small

This week wasn't incremental polish—it was infrastructure-level change. GitHub released the Copilot SDK in public preview, shipped across five languages, and gave you the same production-tested agent runtime that powers GitHub's own tools. At the same time, Copilot cloud agent shed its PR-only constraint, unlocking research sessions, implementation plans, and branch-first workflows.

This matters because GitHub just commoditized agentic orchestration. You no longer need to build your own tool invocation layer, streaming infrastructure, or permission framework—it's yours to embed directly into your applications.

Copilot SDK: Five Languages, One Runtime

The Copilot SDK exposes the same agent runtime powering Copilot cloud agent and Copilot CLI. Instead of reinventing multi-turn sessions, tool calling, and streaming responses, you get production-grade building blocks out of the box.

Now available in:

Node.js / TypeScript: npm install @github/copilot-sdk
Python: pip install github-copilot-sdk
Go: go get github.com/github/copilot-sdk/go
.NET: dotnet add package GitHub.Copilot.SDK
Java: Available via Maven

What you get:

Custom tools and agents: Define domain-specific tools and let the agent decide when to invoke them
Fine-grained system prompt customization: Use replace, append, prepend, or dynamic transform callbacks to customize sections without rewriting the entire prompt
Streaming responses: Token-by-token streaming for responsive UX
Blob attachments: Send images and binary data inline without touching the filesystem
OpenTelemetry support: Built-in distributed tracing with W3C trace context propagation
Permission framework: Gate sensitive operations with approval handlers or mark read-only tools to skip permissions entirely
Bring Your Own Key (BYOK): Use your own API keys for OpenAI, Microsoft Foundry, or Anthropic

The SDK is available to Copilot subscribers and non-Copilot users, including Copilot Free users, and supports BYOK for enterprises. Premium request quota applies when you use Copilot entitlement; BYOK usage is billed through your model provider.

If you've been building custom agents or agentic workflows, this SDK removes the undifferentiated heavy lifting. You're no longer choosing between building your own orchestration layer or being constrained by GitHub's UI—you can embed Copilot's agentic capabilities directly into your platform.

Cloud Agent Escapes the PR Cage

Until this week, working with Copilot cloud agent meant opening a pull request. That constraint is gone. Copilot cloud agent now supports:

Branch-first workflows

Copilot generates code on a branch without creating a PR
Review the full diff before deciding if you're ready for a pull request
Iterate with Copilot until you're satisfied, then click "Create pull request"
Want a PR immediately? Just say so in your prompt and Copilot will create one when the session completes

Implementation plans

Ask Copilot to produce an implementation plan and review the approach before any code is written
Approve or provide feedback on the plan before Copilot proceeds
Once approved, Copilot uses the plan to guide its implementation

Deep research sessions

Kick off research sessions to have Copilot answer questions requiring thorough investigation
Ask broad questions about your codebase and get answers grounded in your repository context
Launch research sessions directly from Copilot Chat

This is a fundamental shift in how you interact with AI agents. Pre-approved plans let you validate the approach before committing compute. Branch-first workflows let you iterate without polluting your PR history. Research sessions turn Copilot into a codebase analyst, not just a code generator.

If you're using agentic DevOps patterns, this unlocks new workflows: research → plan → implement → verify, all without creating a PR until you're ready.

Organization Controls for Cloud Agent

GitHub shipped organization-level runner controls for Copilot cloud agent. Previously, runner configuration lived in per-repository copilot-setup-steps.yml files, making consistent defaults painful.

Now organization admins can:

Set a default runner to be used automatically across all repositories
Lock the runner setting so individual repositories can't override the organization default

This means you can standardize on larger GitHub-hosted runners for better performance or enforce that agents always run on self-hosted runners with access to internal resources. No more repository-by-repository configuration.

Actions Gets Smarter

The April Actions updates shipped three meaningful improvements:

Service container customization

You can now override entrypoint and commands on service containers using entrypoint and command keys in your workflow YAML. The syntax mirrors Docker Compose. This has been a long-standing pain point—no more workarounds.

OIDC tokens support custom properties

GitHub Actions OIDC tokens now include repository custom properties as claims (now generally available). This lets you create granular trust policies with cloud providers based on how your organization classifies repositories—environment type, team ownership, compliance tier—without enumerating individual repository names or IDs.

Azure private networking VNET failover

Azure private networking for GitHub-hosted runners now supports failover networks in public preview. Configure a secondary Azure subnet (optionally in a different region) so workflows keep running if the primary subnet becomes unavailable. Failover can be triggered manually or automatically by GitHub during a regional outage.

Smaller Wins That Matter

Organization custom instructions for Copilot moved to GA for Copilot Business and Enterprise. Organization admins can now set default instructions that guide Copilot's behavior across all repositories. Applied to Copilot Chat on github.com, Copilot code review, and Copilot cloud agent.

GitHub Mobile refreshed its Copilot tab with native session logs, in-app controls for agent sessions, and a clearer overview of chat history. You can now view full session logs, create PRs from completed sessions, and stop running sessions—all from your phone.

Improved search for GitHub Issues hit GA. Natural language search across issue titles and bodies, hybrid search combining semantic and keyword matching, and API access via REST and GraphQL. When search succeeds, the desired result is in the top three 75% of the time, compared to 66% with traditional search.

GitHub also renamed the Security tab to Security & quality, colocating code quality findings alongside security alerts. This lays groundwork for the upcoming GitHub Code Quality GA launch.

What It Signals

The Copilot SDK release is the real story here. GitHub isn't just building AI-powered tools—it's distributing the infrastructure layer that powers them. That's a fundamentally different strategy.

By shipping the SDK across five languages with BYOK support, GitHub is betting that embedded agentic capabilities become standard infrastructure, not just features in GitHub's own products. If you're building developer platforms, CI/CD systems, or internal tools, you now have production-grade agent orchestration out of the box.

Cloud agent's escape from PR-only workflows signals a shift from "AI writes code" to "AI investigates, plans, and implements." Research sessions and implementation plans mean you're validating the approach before committing compute—critical when context engineering determines success.

The pattern is clear: GitHub is building the plumbing for agentic systems and getting out of the way. The SDK, the unlocked workflows, the organization controls—it's infrastructure for teams to build on, not just features to consume.

VS Code Weekly: AI Gets an Effort Dial and Nested Subagents

Hector Flores — Tue, 07 Apr 2026 14:23:13 +0000

Microsoft shipped VS Code 1.113 last week—the third release under their new weekly cadence—and it's starting to feel like the editor is settling into a new rhythm. Not just release rhythm, but product rhythm. The features in 1.113 aren't flashy, but they're the kind that make daily work smoother if you're deep in AI-assisted workflows.

What Actually Shipped

The headline feature is a Thinking Effort selector right in the model picker. If you're using reasoning models like Claude Sonnet 4.6 or GPT-5.4, you can now dial the reasoning intensity up or down per request—Low, Medium, High—without touching settings. The picker shows your current level (e.g., "GPT-5.3-Codex · Medium") so you always know what you're running.

This matters because reasoning effort is a cost-quality tradeoff. Need a quick code explanation? Low effort gets you a faster response. Architecting something complex? Crank it to High and let the model think. I've been using this for about a week now, and it's already changed how I prompt. Quick refactors get Low, system design questions get High. Simple, but the fact that it's right there in the UI makes it feel like a different tool.

The two deprecated settings—github.copilot.chat.anthropic.thinking.effort and github.copilot.chat.responsesApiReasoningEffort—are now deprecated, consolidated into the picker. If you have them in your config, clean them up.

Nested Subagents and MCP Everywhere

Nested subagents are now possible via an opt-in setting: chat.subagents.allowInvocationsFromSubagents. Before, subagents couldn't call other subagents to prevent recursion hell. Now they can, which unlocks genuinely complex multi-step workflows where one agent delegates to another, just like how you'd hand off tasks to teammates.

It's powerful but risky—infinite loops are real. Microsoft kept it opt-in for good reason. If you enable it, set clear depth limits in your workflow.

MCP server support expanded to Copilot CLI and Claude agents. Previously, MCP servers you configured in VS Code only worked for local agents inside the editor. Now they're bridged automatically to CLI and Claude sessions, including workspace-level mcp.json configs. If you've built custom MCP integrations, this makes them useful everywhere, not just in the editor chat.

Session forking also landed for CLI and Claude agents (experimental for CLI via github.copilot.chat.cli.forkSessions.enabled). You can now branch a conversation at any point to explore different approaches without losing the original context. It's Git branches for AI conversations.

The Rest of the Improvements

The Chat Customizations editor consolidates all your agent setup—custom instructions, prompt files, agents, skills, MCP servers, plugins—into one place with tabs and embedded code editing. You open it via Ctrl+Shift+P → "Chat: Open Chat Customizations." If you've been frustrated by scattered settings, this is a relief.

Image viewer for chat attachments now has zoom, pan, navigation, and thumbnail strips. No more squinting at tiny previews when you attach screenshots or the agent generates images. It's also available from the Explorer context menu for image files.

The integrated browser now supports self-signed certificates. You can temporarily trust them (for one week) during local HTTPS development, just like real browsers. It's a small thing, but it removes the friction of switching to Chrome for SSL testing.

Microsoft replaced the default themes with VS Code Light and VS Code Dark—cleaner, more modern, and better across screen types. OS theme syncing now defaults to these for new users, so your editor automatically matches your system's light/dark mode.

What the Weekly Cadence Means

VS Code 1.111 (March 9) was the first weekly stable release. 1.112 followed on March 18, and 1.113 on March 25. This is a dramatic shift from the old monthly cycle with dedicated Endgame testing weeks. Kai Maetzel announced the change on GitHub, saying quality assurance would fold into continuous delivery instead of a distinct phase.

Some developers are nervous about the pace—asking whether there's a way to stay behind a few versions for stability. That's understandable. Microsoft is clearly trying to match the iteration speed of competitors like Cursor and Windsurf, which ship continuously.

But here's the thing: the features in 1.113 feel incremental, not rushed. Nothing in this release screams "we shipped it too early." The Thinking Effort selector is a straightforward UX improvement. Nested subagents are opt-in. MCP bridging is an obvious gap-fill. These are the kinds of improvements you'd expect from a team that's been working on agentic workflows for a while and knows what needs to be better.

The real test isn't whether they can ship weekly—it's whether they can ship weekly without regression explosions. So far, so good. But we're only three weeks in.

The Bottom Line

If you're using AI agents in VS Code—Copilot, Claude, or custom tools—1.113 makes your life measurably better. The Thinking Effort dial alone is worth the update if you're managing token budgets or just want faster responses for trivial tasks. Nested subagents and MCP everywhere make complex workflows finally practical.

If you're not using agents, this release is skippable. New themes are nice, but cosmetic. The browser cert trust is a niche fix. Most of the substance here is in the agentic experience.

I've written before about how context engineering matters more than model choice. The tools in 1.113—session forking, thinking effort control, subagent composition—are all about giving you finer control over that context. You're not just asking the AI a question; you're tuning how it thinks before it answers.

That's where this is headed. Not bigger models. Better control.

Copilot CLI Weekly: /fleet Ships — Parallel Multi-Agent Execution

Hector Flores — Tue, 07 Apr 2026 14:22:42 +0000

/fleet: The CLI Gets a Team

The biggest Copilot CLI release in months landed April 1: /fleet enables parallel multi-agent execution. Instead of working through tasks sequentially, Copilot now dispatches multiple sub-agents to work on different parts of your codebase simultaneously.

GitHub's blog post describes it best: when you run /fleet Refactor the auth module, update tests, and fix the related docs, the orchestrator decomposes your task into discrete work items, identifies what can run in parallel, and dispatches independent items as background sub-agents. Think of it as a project lead assigning work to a team.

This isn't just faster sequential execution — it's fundamentally different architecture. The orchestrator plans, breaks down dependencies, dispatches waves of parallel work, and synthesizes results. Each sub-agent gets its own context window but shares the filesystem. They can't talk to each other; only the orchestrator coordinates.

The key to making /fleet work is writing prompts that parallelize well. GitHub's guidance is clear: be specific about deliverables, set explicit boundaries (which files each track owns), and declare dependencies when they exist. Vague prompts lead to sequential execution because the orchestrator can't identify independent pieces.

You can also reference custom agents defined in .github/extensions/ to assign different models or tools to different tracks. Want a heavy model for complex logic and a light one for boilerplate docs? /fleet Use @technical-writer.md as the agent for all docs tasks and the default agent for code changes.

This is the kind of feature that changes how you think about the tool. I've been covering Copilot CLI since it shipped, and /fleet is the clearest signal yet that GitHub is building toward a multi-agent development platform. Cross-link to my earlier take on agentic workflows — this is what I was talking about.

Four Releases in Four Days

Between March 31 and April 3, GitHub shipped four releases (v1.0.14, v1.0.15, v1.0.16, v1.0.17). Here's what matters:

Built-in Skills (v1.0.17 — April 3)

Built-in skills are now included with the CLI, starting with a guide for customizing Copilot cloud agent's environment. This is the first step toward a skill ecosystem that doesn't require manual configuration. Skills are packaged instructions that agents can reference to handle specific tasks or contexts. Expect this to expand rapidly.

MCP OAuth flows now support HTTPS redirect URIs via a self-signed certificate fallback, improving compatibility with OAuth providers that require HTTPS (like Slack). The /resume session picker also loads significantly faster with large session histories — a small quality-of-life win that adds up if you're resuming sessions daily.

MCP and Permission Hooks (v1.0.16 — April 2)

Version 1.0.16 introduced a PermissionRequest hook to programmatically approve or deny tool permission requests. If you're building automation workflows with the CLI SDK, this is a big deal — you can now script approval logic instead of relying on interactive prompts.

MCP tool calls now display the tool name and parameter summary in the timeline, making it easier to follow what's happening when agents invoke external servers. MCP server reconnects also work correctly after directory changes, and BYOK Anthropic providers now respect maxOutputTokens limits.

Export to HTML, OAuth Device Flow, Config CamelCase (v1.0.15 — April 1)

Version 1.0.15 shipped alongside /fleet with several standout features:

/share html exports sessions and research reports as self-contained interactive HTML files. Great for sharing context with teammates who don't have CLI access or for archiving sessions outside of Copilot's storage.
Device code flow (RFC 8628) as a fallback for MCP OAuth in headless and CI environments. This closes a gap for teams running the CLI in automated pipelines.
/mcp auth command with re-authentication UI for MCP OAuth servers, including account switching support. Managing multiple OAuth-protected MCP servers is now a first-class workflow.
Config keys now prefer camelCase (askUser, autoUpdate, logLevel, etc.). Snake_case still works, but the CLI is standardizing on JavaScript conventions. A small change, but it signals ongoing maturity in the SDK and config system.
The Copilot mascot now blinks with subtle eye animations in interactive mode. Yes, really. It's a delightful detail that reminds you there's a team sweating UX polish even as they ship major features.

The release also includes ~8 UX fixes: autopilot no longer continues after Escape or Ctrl+C, keystrokes typed during loading are no longer lost, the CLI exits immediately after a session ends instead of waiting up to 10 seconds, and Home/End/Page Up/Page Down now work in the diff viewer.

27 Fixes and Improvements (v1.0.14 — March 31)

Version 1.0.14 was a cleanup release with 27 bug fixes and stability improvements. Highlights include:

Images correctly sent to Anthropic models with BYOM
Model picker selection now overrides the --model flag for the current session
Grep tool handles large files and long lines without running out of memory
CLI startup time reduced by running terminal detection, auth, and git operations in parallel
V8 compile cache reduces parse and compile time on repeated invocations
MCP registry lookups are more reliable with automatic retries and timeouts

Nothing flashy, but these are the kinds of fixes that make the tool feel solid in daily use.

Copilot Cloud Agent Goes Beyond Pull Requests

On March 31, GitHub announced that Copilot cloud agent is no longer limited to pull-request workflows. You can now:

Generate code on a branch without opening a pull request. Review the full diff, iterate with Copilot, and only create a PR when you're ready.
Ask Copilot to produce an implementation plan and review the approach before any code is written. Once approved, Copilot uses the plan to guide its implementation.
Kick off deep research sessions to answer broad questions about your codebase, grounded in repository context.

This is a significant shift. Copilot cloud agent is transitioning from a "create PR" workflow to a general-purpose coding assistant that works across planning, research, and implementation modes. The CLI's /fleet feature and the cloud agent's new flexibility are clearly part of the same vision: enabling developers to orchestrate AI agents for complex, multi-phase workflows.

For context, see my previous coverage of Copilot CLI's biggest week and how to avoid common mistakes with custom agents. The pieces are coming together.

What This Signals

Four days, four releases, a major blog post, and a significant expansion of Copilot cloud agent's capabilities. The pace is relentless, and the direction is clear: GitHub is building a multi-agent development platform.

/fleet isn't just a parallel execution feature — it's a programming model. You write prompts that decompose into independent tracks, each handled by a sub-agent with its own context. The orchestrator coordinates, but the agents work autonomously. This is the same pattern used in production multi-agent systems, now accessible via a CLI command.

The built-in skills, permission hooks, MCP OAuth improvements, and cloud agent planning modes all point toward a future where developers compose AI workflows instead of writing code manually. We're not quite there yet, but the foundation is being laid at a rapid pace.

The Bottom Line

If you haven't tried /fleet yet, start with something small — a refactor across multiple files, docs and tests in parallel, or a feature that spans API, UI, and tests. See how the orchestrator decomposes the work. Adjust your prompts based on what parallelizes and what doesn't. You'll quickly learn when /fleet pays off and when a regular prompt is simpler.

The CLI shipped ~55 features and fixes across four releases in four days. The tool is maturing fast, and the vision is becoming concrete: a multi-agent platform where developers orchestrate AI teams instead of writing every line themselves. That future is arriving sooner than I expected.

Azure Weekly: Developer Tools Get Smarter, Database Pricing Gets Better

Hector Flores — Tue, 07 Apr 2026 14:22:35 +0000

What Shipped This Week

Azure's March releases wrapped with a clear signal: Microsoft is doubling down on making Azure easier to use, cheaper to run, and more aligned with how developers actually build AI-native applications. The Azure Developer CLI got seven updates in one month, database pricing finally caught up to AWS, and .NET Aspire graduated to GA on App Service.

If you're building cloud-native or AI-enabled apps on Azure, this is the most impactful week since agentic infrastructure went GA last month.

Azure DevCLI: Local AI Agent Debugging and Copilot Integration

The Azure Developer CLI (azd) shipped seven releases in March 2026—versions 1.23.7 through 1.23.13. The headline features are all about closing the loop between local development and Azure deployment for AI agents.

GitHub Copilot integration in azd init: You can now scaffold new projects with GitHub Copilot assistance directly in the CLI. The flow checks for uncommitted changes before modifying files, prompts for Model Context Protocol (MCP) server tool consent upfront, and guides you through project setup conversationally. When commands fail, azd offers a multi-step troubleshooting flow—explain the error, get guidance, let the agent apply a fix, and retry—without leaving the terminal.

Local AI agent debugging: This is the big one. You can now run and debug AI agents locally before deploying to Azure. That means full breakpoint debugging, local model testing, and MCP tool validation on your machine. No more deploy-and-pray workflows where you only discover agent behavior issues after pushing to Container Apps.

Container App Jobs deployment: Azure Container App Jobs are now first-class citizens in azd. Use the existing host: containerapp configuration—your Bicep template determines whether the target is a Container App or a Container App Job. No extra configuration needed. This matters because batch workloads, scheduled AI agent tasks, and event-driven processing all run better as Jobs than always-on Apps.

Infrastructure preflight validation: Before deploying to Azure, azd now validates Bicep parameters and configuration locally. It catches missing parameters and type mismatches without a round-trip to Azure—saving you from failed deployments and unnecessary quota consumption.

I've been using azd since it launched, and this release fundamentally changes the developer experience. The local-first workflow for AI agents means you're not burning Azure credits to debug basic tool connectivity issues. The GitHub Copilot integration turns "read the docs" into "ask the CLI." And Container App Jobs support finally closes the gap between development templates and production architectures.

Azure Savings Plan for Databases: Flexible Discounts That Actually Make Sense

On March 18, Microsoft announced general availability of the Azure Savings Plan for Databases. The premise is simple: commit to a fixed hourly spend for one year, and Azure applies up to 35% discounts across your database usage automatically. No region lock, no service lock, no SKU lock.

What's covered: Azure SQL Database (including Hyperscale and serverless tiers), SQL Managed Instance, Azure Database for PostgreSQL, Azure Database for MySQL, Azure Cosmos DB, and SQL Server on Azure VMs or Arc-enabled servers. SQL Server licensing on VMs is billed at standard rates and not discounted under the plan.

Why the flexibility matters: Traditional Azure Reservations are powerful but punishing if your architecture changes. You lock a discount to a specific service, region, and configuration—great for stable workloads, painful for anything in motion. In practice, most teams operating in 2026 are mid-migration from on-prem SQL Server to Azure SQL, scaling PostgreSQL across new regions, or shifting to Cosmos DB to support AI retrieval patterns. A reservation that penalizes you for evolving is a reservation that fights your roadmap.

The Savings Plan flips this. You commit a dollar amount per hour, and Azure applies discounts to whichever eligible services you actually run—in whatever configuration, across whatever regions. When your Cosmos DB usage grows at the expense of SQL MI, your savings commitment follows the usage automatically.

Savings Plans and Reservations aren't mutually exclusive: Azure applies reservation discounts first (deeper discounts, but restricted to matching configurations). The Savings Plan then picks up any remaining eligible usage not covered by a reservation. For teams with stable workloads in some areas and dynamic growth in others, using both in combination gives maximum coverage.

This is how AWS Savings Plans have worked for years. Azure's implementation lands with the same flexibility—and it's overdue. For teams carrying multi-database environments or long migrations, this removes the "commit or stay flexible" tradeoff that's been a real friction point in Azure cost management.

.NET Aspire on Azure App Service Hits GA

.NET Aspire on Azure App Service is now generally available. This makes it easier to take distributed .NET applications from local development to a fully managed production environment on Azure App Service.

Aspire is Microsoft's opinionated stack for building cloud-native .NET apps—think distributed services, observability, configuration, and service discovery baked in. The GA release means you can now use azd up to deploy Aspire apps directly to App Service with production-grade support, monitoring, and scaling.

What changed: App Service now natively understands Aspire's manifest format. Service-to-service communication, dependency injection, and telemetry wiring all work out of the box. You don't need to manually configure service bindings, connection strings, or distributed tracing endpoints.

If you're building microservices or event-driven architectures in .NET, Aspire on App Service is now the fastest path from dotnet new aspire to production. It's also a strong signal that Microsoft is betting on opinionated frameworks—not just generic PaaS—as the way forward for developer experience.

Visual Studio March Update: Build Your Own Custom Copilot Agents

The Visual Studio March 2026 update shipped with a custom agent builder for GitHub Copilot. This lets you create specialized Copilot agents tailored to your codebase, workflows, or team conventions.

The builder supports custom instructions, context injection, and tool definitions. You can create an agent that understands your team's architectural patterns, references your internal docs, or enforces specific coding standards—all within the Copilot interface developers already use.

This is part of a broader trend: Microsoft is moving from "one Copilot for everyone" to "a Copilot ecosystem you customize." The GitHub Copilot SDK (which I wrote about previously) already enables this for app developers. Now Visual Studio brings it directly into the IDE for platform teams and DevEx engineers.

What It All Means

March's releases have a unifying theme: Azure is investing in developer velocity and cost flexibility—not just raw infrastructure.

The Azure DevCLI updates are all about local-first workflows and conversational tooling. The Savings Plan for Databases acknowledges that modern cloud architectures are fluid, not static. Aspire on App Service is an opinionated framework play. Visual Studio's custom agents let teams adapt AI tooling to their context.

These aren't service launches. They're workflow optimizations. Microsoft is betting that what wins developers in 2026 isn't the most compute or the most AI models—it's the platform that makes building, deploying, and operating cloud-native apps the least painful.

For teams building on Azure, these updates deliver immediate ROI. Local AI debugging cuts iteration time. Database savings plans cut costs without architectural constraints. Aspire cuts boilerplate. Custom agents cut context-switching.

The question isn't whether these features matter. It's whether your team is using them yet.

GitHub Weekly: Actions Gets Serious About Supply Chain Security

Hector Flores — Tue, 07 Apr 2026 14:22:10 +0000

GitHub dropped one of the most substantial platform updates I've seen in months. The headline: GitHub Actions is getting a full-stack security overhaul. But there's also meaningful movement on agent workflows, Copilot integration across Issues and Slack, and a data usage policy change that's worth understanding.

Let's break down what shipped and what it means.

GitHub Actions 2026 Security Roadmap: The Big One

GitHub published their 2026 security roadmap for Actions this week, and it's not incremental—it's structural. If you run CI/CD on GitHub Actions (and who doesn't), this roadmap signals a major shift toward treating your build infrastructure like the critical attack surface it actually is.

The context: supply chain attacks targeting CI/CD aren't slowing down. Recent incidents like tj-actions/changed-files, Nx, and trivy-action all followed the same playbook—compromise a dependency, exploit over-permissioned workflows, exfiltrate credentials via unrestricted network access. GitHub's response addresses each layer.

Three-Layer Security Model

1. Ecosystem: Dependency Locking for Workflows

The biggest change: GitHub is introducing workflow-level dependency locking via a new dependencies: section in workflow YAML. Think go.mod + go.sum, but for your entire Actions dependency graph.

Today, most workflows reference actions by mutable tags (uses: actions/checkout@v4). That means what runs in CI isn't deterministic—if a tag gets repointed or a dependency is compromised, the change propagates immediately across every workflow that references it.

With dependency locking, every direct and transitive dependency gets locked to an immutable commit SHA with cryptographic hashes. Updates show up as reviewable diffs in pull requests. Hash mismatches fail fast before jobs even run.

Timeline: Public preview in 3-6 months, GA in 6 months.

2. Attack Surface: Policy-Driven Execution

GitHub is adding centralized workflow execution policies built on their ruleset framework. Instead of configuring security per-workflow, you define org-level policies that control:

Who can trigger workflows (individual users, roles, trusted apps like Dependabot or Copilot)
Which events are allowed (prevent dangerous patterns like pull_request_target org-wide)

This matters because many CI/CD attacks exploit confusing event behavior or unclear permission boundaries. A centralized policy model means you can block entire classes of attacks without editing thousands of workflow files.

Policies support evaluate mode first—rules log violations without enforcement, so you can assess impact before flipping the switch.

Timeline: Public preview in 3-6 months, GA in 6 months.

Bonus: Scoped Secrets

Secrets are getting fine-grained scoping. Instead of repository-wide or org-wide secrets that flow broadly by default, you'll be able to bind credentials to:

Specific branches, environments, or workflow paths
Trusted reusable workflows without requiring callers to pass secrets explicitly

This eliminates implicit secret inheritance and makes trust boundaries explicit. Combined with a permission model change (write access no longer grants secret management by default), this moves Actions toward least-privilege credentials.

3. Infrastructure: Endpoint Monitoring and Egress Firewall

GitHub is treating CI/CD runners as protected endpoints with two new capabilities:

Actions Data Stream: Near real-time execution telemetry streamed to your own systems (Amazon S3, Azure Event Hub, Azure Data Explorer). You get workflow execution details, dependency usage patterns, and (future) network activity logs—making CI/CD observable like any other production system.

Native Egress Firewall: A Layer 7 firewall that operates outside the runner VM. Even if an attacker gains root inside the runner, they can't modify the firewall. You define egress policies (allowed domains, IP ranges, HTTP methods, TLS requirements), and the firewall enforces them.

The firewall supports two modes: monitor (audit all outbound requests without blocking) and enforce (block anything not explicitly allowed). This gives you a safe adoption path—observe traffic first, build allowlists based on real data, then turn on enforcement.

Actions Data Stream timeline: Public preview in 3–6 months, GA in 6–9 months. Native Egress Firewall timeline: Public preview in 6–9 months.

Custom Images for GitHub-Hosted Runners Hit GA

After a public preview that started in October 2025, custom images for GitHub-hosted runners are now generally available.

This feature lets you start with a GitHub-curated base image and build your own VM image with preinstalled tools, dependencies, certificates, and configurations. The benefit: faster workflow runs, consistent environments, and centralized control over how build environments are standardized and governed at scale.

If you were already using custom images during preview, nothing changes—your workflows continue working as-is.

Agent Sessions Surface in Issues and Projects

GitHub shipped agent activity tracking directly into Issues and Projects this week. When a coding agent (Copilot, Claude, Codex, etc.) is assigned to an issue, its session now appears in the sidebar with live status: queued, working, waiting for review, or completed.

In Projects, you can toggle on Show agent sessions in table and board views to see agent activity across a large body of work at a glance.

This is a small but meaningful UX improvement. If you're running agentic workflows at scale, being able to see agent status directly in your planning tools closes a visibility gap.

Copilot Can Now Edit PRs Directly

Instead of opening a new PR on top of your existing PR, you can now mention @copilot in a pull request to ask it to make changes directly. Use cases:

@copilot Fix the failing tests
@copilot Address this comment
@copilot Add a unit test covering the case when the model argument is missing

Copilot works in a cloud-based dev environment, validates changes with your tests and linter, then pushes. If you still want the old behavior (opening a separate PR), just ask: @copilot open a PR to fix the failing tests.

Available with all paid Copilot plans. Business and Enterprise admins need to enable the coding agent first.

Create GitHub Issues from Slack with Copilot

The GitHub app for Slack now supports creating GitHub Issues via natural language. Mention @GitHub in any channel, describe the work, and it creates structured issues—titles, bodies, assignees, labels, milestones, even sub-issues.

Key features:

Conversation mode: Iterate on issues in a Slack thread before creation
Channel-level instructions: Set default working repos with @GitHub settings
Issue flex pane: View created issues directly from Slack

This builds on the Copilot coding agent Slack integration from last October. If your team already lives in Slack, this reduces friction between discussion and tracking.

Copilot Data Usage Policy Update: Know What You're Opting Into

On March 25, GitHub announced an update to Copilot interaction data usage. Starting April 24, interaction data from Copilot Free, Pro, and Pro+ users will be used to train and improve AI models unless you opt out.

What gets collected (if you don't opt out):

Outputs you accept or modify
Inputs sent to Copilot (code snippets, context around cursor)
Comments, documentation, file names, repo structure
Interactions with Copilot features (chat, inline suggestions)
Feedback (thumbs up/down)

What doesn't get collected:

Copilot Business or Enterprise interaction data
Data from users who opt out
Content from issues, discussions, or private repos "at rest" (though Copilot does process private repo code when you're actively using it)

How to opt out: Go to settings → Privacy. If you previously opted out of data collection for product improvements, your preference is preserved.

This aligns with industry practices (OpenAI, Anthropic, Google all use interaction data for training unless you opt out). GitHub says they've already seen measurable acceptance rate improvements by training on Microsoft employee interaction data, and they believe real-world data improves model quality.

My take: This is a reasonable policy if you're on Free or Pro and want to contribute to model improvement. But if you work with proprietary codebases or sensitive patterns, verify your opt-out status before April 24. Business and Enterprise users are unaffected.

The Bottom Line

GitHub's Actions security roadmap is the story of the week. Dependency locking, centralized execution policies, scoped secrets, and a native egress firewall represent the most significant security investment in Actions I've seen since the platform launched. If you run production CI/CD on GitHub, these changes will fundamentally alter how you think about supply chain risk.

The agent and Copilot updates are iterative but useful—agent sessions in Issues solve a real visibility problem, PR edits reduce friction, and Slack integration meets teams where they already work.

The data usage update is notable primarily for transparency. If you care about what happens to your interaction data, now's the time to review your settings.

GitHub is clearly signaling that 2026 is the year they shift platform infrastructure—especially CI/CD—from flexible-by-default to secure-by-default. The roadmap reflects that. Whether you're ready or not, these changes are coming.