Add the Directory for This Session. Mask the Host Before You Save. Attribute the Decision.

At a glance

• The newest Copilot CLI build on the main npm channel limits extra sandbox directories to the session that asked for them.
• Sandbox settings now flag likely secrets and accept masking hosts before you save, and the timeline names the source of every permission decision.
• Enterprise admins can tie Copilot telemetry to a person while prompt, response, tool and policy capture all stay off unless switched on.
• Claude Code, Codex, Gemini CLI and Cursor held still, and Copilot's only newer builds are pre-releases.

Monday finally moved a channel we track, and the move is about scope rather than new models, because the Copilot CLI update promotes a set of sandbox and permission changes that sat in Friday's pre-releases into the build most people install. The practical effect is that a developer can widen sandbox access for one session without rewriting policy, handle secrets in sandbox settings with a prompt instead of memory, and see afterward which actor approved a risky call. Later the same evening GitHub gave administrators a matching control on the reporting side, so an audit can name the person behind agent activity without also collecting what they typed. Treat today as the day to move Copilot CLI to v1.0.96 where you run sandboxed sessions, read the permission labels in one real timeline, and decide whether identity attribution belongs in your telemetry policy.

Top Stories

1. Copilot CLI v1.0.96 scopes directory grants to the session and names each permission decision

GitHub published Copilot CLI v1.0.96 to npm at 2:51 PM ET Monday, and the GitHub release followed a minute later. Every line in it first appeared in the v1.0.96 pre-releases on Friday, at 3:21 PM, 8:12 PM and 10:13 PM ET, so Monday is when these changes reach the latest tag rather than when they were written. The /add-dir command now grants sandbox access to the added directories for the current session, which the pre-release notes filed as a fix. Interactive sandbox settings now suggest possible environment secrets and let you add masking hosts before the settings are saved. The timeline now shows whether you, Assisted Permissions, policy or unattended fallback made each permission decision.

The rest of the release is smaller. /allow-all stays available during startup while enterprise policy is still resolving, /user list shows the authentication source for each signed-in account, retry progress messages now appear before a recovered response after a transient model failure, and interactive sessions in git repositories reach the input prompt sooner. Signed-out model completions also stop showing an authentication warning when an account-owned catalog is unavailable. The case-insensitive model IDs in /model and /config are in this release too, but Saturday's brief already reported them from the v1.0.96-2 pre-release.

Masking hosts are a separate line from the sandbox credential injectHosts keys that v1.0.95 added to copilot config, which we covered in our Saturday brief, "Read the Large File Once. Compact the Subagent Early. Stable Stepped to v2.1.287." The release notes do not define masking hosts beyond that one line or give a settings key for them, so look for the option in the interactive sandbox settings rather than guessing a name.

Practical dev impact: When an agent needs a build output or scratch folder for one task, /add-dir now gives it that access for the session and no longer, so a temporary need does not quietly become part of your standing sandbox policy. Because the settings screen now proposes likely secrets before you save, the moment you configure the sandbox becomes the natural point to decide which values stay masked. The timeline labels matter most for teams that mix Assisted Permissions with managed policy, since after an unexpected command you can see whether a person, the permission judge, a policy rule or the unattended fallback let it through, and then fix the right layer.

2. GitHub separates identity from content in Copilot telemetry

GitHub's Changelog post, dated Monday and published at 6:38 PM ET, lets enterprise administrators use telemetry in managed settings to attribute Copilot activity to a user without collecting prompts, responses or tool content. The telemetry.capture.identity setting adds three attributes to OpenTelemetry data: user.name, which is the authenticated Copilot account and currently the GitHub login, process.user.name for the local operating system account, and host.name for the machine. Identity capture is off by default and stays separate from the existing pseudonymous user identifier.

Administrators can also control five content classes independently. They are prompts, responses, toolArguments, toolOutput and policyDetail, the last of which covers raw policy details such as sandbox filesystem paths. Every class is off by default, and explicit managed values take precedence over local settings, SDK configuration and environment variables. The older captureContent setting remains as a legacy shorthand for the five content classes, but it never turns on identity. GitHub says these fine-grained controls work in Copilot CLI, the GitHub Copilot app and VS Code sessions that use Agent Host.

Practical dev impact: Teams that only need to know who ran an agent can now switch on identity alone, so an audit trail no longer forces them to collect source code, commands or tool results along with it. GitHub warns that prompt, tool and policy capture can include file contents, commands and workspace or profile paths, so enable only the classes an audit actually needs and send them to an approved collector. Developers should also expect that a managed value will override anything they set locally or through environment variables.

Practical Impact Analysis

The two stories line up because they cover both ends of the same agent session. Copilot CLI v1.0.96 tightens what happens inside the session, since access can be granted for one task and every approval carries a named source, while the telemetry controls decide what leaves the machine once the session is over. Together they let a team answer who approved a command and who was running the agent without logging everything that agent saw.

The rollout order follows from that. Update the CLI first, because the session-only grant and the permission labels help every developer straight away, and they do not depend on any telemetry decision. After that, administrators can agree on a telemetry policy that starts with identity alone and adds a content class only when a named audit requires it, treating policyDetail as sensitive because it can expose sandbox paths. Our view is that nothing else needs a new pin this morning. At 6:01 AM ET npm showed Claude Code stable at v2.1.287 with latest and next at v2.1.296, Codex latest at v0.162.1 with alpha at v0.163.0-alpha.5, and Gemini CLI latest at v0.63.0 with preview at v0.64.0-preview.1 plus a new nightly, v0.65.0-nightly.20261013. Copilot's prerelease tag is v1.0.97-2, published at 9:08 PM ET Monday, so keep it off fleet machines. Cursor's main changelog still leads with Remote Control, and the Cursor CLI changelog still ends at v2026.10.08.

Tutorial

We have not run this script end to end on every platform, so run it before you approve any update today. It prints the Copilot CLI channel and your local version, and the install line is commented out and labeled by channel, so nothing changes unless you uncomment it on purpose.

#!/usr/bin/env bash
# 1. Channel pointers. At 6:01 AM ET Tue 13 Oct npm showed Copilot latest v1.0.96 and prerelease v1.0.97-2.
npm view @github/copilot dist-tags --json

# 2. What this machine runs
copilot --version

# 3. Copilot CLI latest channel, npm installs only, npm latest at 6:01 AM ET Tue 13 Oct:
# npm install -g @github/copilot@1.0.96

If the latest tag no longer reads v1.0.96, a newer build shipped after 6:01 AM ET, so read its release notes before you update. Native installs follow their own pointers, so do not mix npm and native installs of the same tool on one machine. After updating, start a session in a repository, run /add-dir for a scratch directory, and let the agent touch it once so a permission decision appears in the timeline with its source label. The release notes give no argument syntax beyond the command name, so check the CLI's own help rather than guessing. Open the interactive sandbox settings, review any suggested environment secrets, and add a masking host before you save. Start a fresh session afterward and confirm the added directory is no longer in the sandbox.

Recommended AI prompt

Copy this paragraph into ChatGPT, Claude, Gemini, Grok, or whatever AI you use.