Rubber Duck Now Works With Any Model Family
On May 7, GitHub expanded Rubber Duck — the cross-family review agent I covered when it launched last month — to work bidirectionally across model families. When Rubber Duck first shipped in experimental mode, it was Claude-only: pick a Claude model as your orchestrator, and Rubber Duck would dispatch GPT-5.4 to review the work. That closed 74.7% of the performance gap between Sonnet and Opus on hard multi-file problems.
The May 7 changelog flips the script: if you’re using a GPT model as your orchestrator, Rubber Duck now dispatches a Claude-powered critic. The same architectural review, subtle bug catching, and cross-file conflict detection now applies to GPT-driven sessions.
For Claude sessions, the update upgrades the reviewer model to GPT-5.5 (previously GPT-5.4), bringing a stronger second opinion to the table. The net effect is that Rubber Duck is no longer a Claude feature — it’s a universal cross-family review layer that works regardless of which model you pick as your primary orchestrator.
To use it, run copilot and toggle /experimental on. You’ll see Rubber Duck critiques surface after file edits, during planning checkpoints, and when the agent requests a second opinion. The critiques are terse and high-signal: “This migration doesn’t handle the foreign key cascade,” “The batch size will OOM on inputs > 10K rows,” “This assumes UTC but the DB stores local time.” The kinds of things a second pair of eyes catches.
I’ve been running with Rubber Duck enabled since April and the false positive rate is low. When it flags something, it’s usually right. The feature still lives in /experimental, but it feels production-ready. I expect it to graduate soon.
Enterprise-Managed Plugins Hit Public Preview
On May 6, GitHub shipped enterprise-managed plugins in public preview, giving enterprise admins the ability to configure and distribute plugins across all Copilot CLI users in their org. This is a governance and onboarding win.
Before this, if you wanted every engineer in your enterprise to have access to a custom agent, an internal MCP server, or a standard set of hooks, you distributed documentation and hoped people followed it. “Clone this repo, copy these files, run this install script, restart your CLI.” Some people did it. Most didn’t. Onboarding new hires meant repeating the process.
With enterprise-managed plugins, admins define a settings.json file in a .github-private/.github/copilot/ repo and Copilot CLI pulls it automatically for any user authenticated via Copilot Business or Enterprise. The settings file specifies plugin marketplaces, auto-installed plugins, and baseline configurations. When a user runs copilot, the client syncs the enterprise config and applies it.
This means you can:
- Standardize custom agents — If your team built a deployment agent or a codebase navigator, you can ensure every CLI user has it without manual setup.
- Enforce hooks and MCP configs — Define hooks that run on every session (e.g., to enforce context rules or inject environment-specific data) and they’re always active across your enterprise.
- Reduce setup friction — New hires authenticate with Copilot CLI and the enterprise baseline just works.
The configuration lives in the same .github-private repo you’d use for custom agents (if you’ve already set one up under AI controls in your enterprise settings). If you haven’t configured a source org yet, you’ll need to do that first via the Agents page in your enterprise admin panel.
The practical impact here is that enterprises can finally treat Copilot CLI customizations as infrastructure-as-code instead of tribal knowledge. If you’re managing Copilot for a large org, this is the feature you’ve been waiting for since the CLI went GA.
Hooks Can Now Bypass the LLM Entirely
In the v1.0.44-3 prerelease (published May 8), GitHub added the ability for userPromptSubmitted hooks to handle requests directly and return a response without making a model call. This is a significant architectural shift for what hooks can do.
Previously, hooks were preprocessors: inspect the user’s prompt, modify it, add context, or reject it, but you always handed control back to the LLM for the actual response. Now hooks can be full interceptors. If a hook decides it knows how to handle the request without involving the model, it can return the response itself.
The use cases are obvious:
- FAQ or documentation lookup — If the user asks “What’s the deploy command?” and you have a knowledge base, the hook can return the answer instantly without burning a model call.
- Canned responses — Common requests like “Show me the latest logs” or “What’s my account status?” can be handled by hitting an API directly.
- Policy enforcement — Block certain requests entirely and return a rejection message without consulting the LLM.
- Latency-critical flows — For requests where you know the answer and speed matters, skip the model inference latency.
The implementation is clean: hooks return a response field in the result, and if it’s present, the CLI surfaces it to the user and ends the turn. No model call, no token usage, instant feedback. This pairs nicely with the enterprise plugin system — you can distribute hooks that intercept high-frequency patterns and handle them locally, reducing load and improving response time.
This is still in prerelease, so expect the API to stabilize before it hits the main release channel. But the direction is clear: hooks are evolving from passive filters to active participants in the request/response flow.
Other Highlights from v1.0.43 and v1.0.44
- Security fix for RCE — v1.0.43 patched a vulnerability where malicious bare repositories nested inside a project could trigger remote code execution. If you’re working in untrusted codebases, update immediately. (CVE details)
- Auto mode now uses server-side routing — The
automodel selector delegates routing decisions to the server for more dynamic real-time model selection. - Faster multi-account switching —
/user listand/user switchare noticeably faster for users managing multiple GitHub accounts. - Shell aliases work in ! commands — v1.0.44-1 fixed a long-standing bug where shell aliases and rc file settings weren’t respected in
!prefix commands. - Prerelease update flag —
copilot update --prereleasenow lets you fetch the latest prerelease build without manually downloading from GitHub. - Username in statusline — You can now toggle the active account display in the footer via
/statusline, useful when switching between personal and work accounts.
The Bottom Line
This week’s updates reinforce two themes: cross-model collaboration is table stakes (Rubber Duck going universal), and enterprise adoption is accelerating (centralized plugin distribution, hook-based governance). The fact that hooks can now bypass the LLM entirely is a quieter change, but it’s architecturally significant — it shifts the CLI from a stateless LLM wrapper to a programmable agentic runtime.
If you’re running Copilot CLI in an enterprise context, the plugin management feature is worth setting up this week. If you’re experimenting with /experimental, turn on Rubber Duck and watch how often the second opinion catches things your primary model missed. And if you’re building custom hooks, start thinking about what you can handle locally without a model call — the performance gains are substantial for high-frequency patterns.
Next week I’ll be digging into the security advisory in more detail and how the nested bare repo RCE could have been exploited. Until then, copilot update and ship something.