Copilot CLI 1.0.46 Makes Read-Only Agent Authority a Product Decision

GitHub Copilot CLI 1.0.46 is the kind of release note most teams will scroll past and then rediscover six months later in a security review. The release is small: a deprecation warning, a PowerShell shim fix, wrapped long lines in diff view, a mid-turn crash fix, and one approval-policy change. But that approval-policy change is the story: read-only gh commands such as list, view, status, and diff are now auto-approved without interrupting the user.

That sounds like a quality-of-life tweak. It is actually a product decision about agent authority.

For the last year, the industry has treated coding-agent safety as a binary switch: either the agent asks before doing things, or it runs loose and everyone pretends the sandbox is enough. That framing is too crude for real engineering work. A useful agent needs to inspect issues, pull requests, diffs, CI state, and repository metadata constantly. If every harmless-looking read blocks on a modal prompt, developers learn the worst possible habit: approve first, think never. Approval fatigue is not just annoying. It is how permission systems become wallpaper.

GitHub is making the correct bet that some categories of inspection should be quiet by default. The harder question is whether teams understand what “read-only” does and does not mean.

Read-only is not the same as harmless

The release note is precise enough: “Read-only gh CLI commands (list, view, status, diff, etc.) are auto-approved without prompting for user confirmation.” Those commands do not mutate GitHub state. They will not merge a pull request, close an issue, push a branch, or edit a release. For day-to-day agent work, that distinction matters. An agent that can run gh pr view and gh pr diff without stopping can build context before making a recommendation. An agent that has to ask for permission every time it reads a PR is mostly teaching the user to become a button-clicking peripheral.

But “does not write” is only one axis of risk. Read operations can expose private repository names, unreleased roadmap items, customer references in issues, vulnerability details in private advisories, logs from failed CI jobs, branch naming conventions, employee names, internal service URLs, and code diffs that were never meant to leave the organization. In an agent workflow, the sensitive event may not be the gh read itself. It may be what happens next: the retrieved context gets summarized into a model prompt, persisted in an agent trace, exported to an observability backend, copied into a debugging artifact, or combined with another tool call.

That is the governance lesson hiding in a tiny CLI release. Agent permission models need at least three separate questions: can this action mutate state, can it disclose sensitive data, and where can the resulting context be retained or transmitted? A read-only command answers only the first question.

The flight recorder is becoming the control plane

The surrounding Copilot telemetry work makes this more interesting. Microsoft’s VS Code documentation says Copilot Chat can export traces, metrics, and events through OpenTelemetry for agent interactions, LLM calls, tool executions, token usage, and more. It describes a trace tree with spans for the overall agent invocation, chat/LLM calls, and tool execution. It also documents metrics such as gen_ai.client.operation.duration, gen_ai.client.token.usage, copilot_chat.tool.call.count, copilot_chat.agent.invocation.duration, copilot_chat.pull_request.count, and copilot_chat.cloud.session.count.

For background and CLI agents, the docs go further. Copilot CLI sessions can produce trace hierarchy that includes subagents, permissions, hooks, and tool calls. Terminal CLI sessions appear as independent root traces under the github-copilot service. In other words, GitHub is not merely making the agent more autonomous; it is adding the observability primitives required to reconstruct what the agent did after the fact.

That matters because the approval prompt is a terrible audit log. “User approved command” is useful, but it is not enough. A team investigating an agent-generated change needs to know which issue the agent read, which PR diff it inspected, which tools it called, which model produced the plan, how many turns occurred, whether subagents were involved, which permissions were requested, which hooks fired, and whether the human accepted the resulting edit. Without that record, reviewing an agent run is archaeology with missing layers.

OpenTelemetry is a reasonable foundation because it plugs into systems engineers already use: Jaeger, Grafana Tempo, Honeycomb, Datadog, Aspire Dashboard, and the usual OTLP collectors. It also forces a useful discipline. If a coding agent is becoming part of the delivery system, its behavior should be observable like any other distributed system component. Tool calls are not magic. They are operations. Latency, failures, retries, permissions, and outputs should be inspectable.

The privacy footgun has a setting name

The sharp edge is content capture. GitHub’s monitoring docs say OTel is off by default and, when enabled, captures metadata by default rather than full prompt or tool content. Full content capture requires the github.copilot.chat.otel.captureContent setting or COPILOT_OTEL_CAPTURE_CONTENT=true. The docs are explicit that enabling it can include code, file contents, user prompts, system prompts, tool schemas, tool arguments, and tool results.

That is the setting teams should treat like a production data-export control, not a debugging convenience. Metadata-only traces can answer many operational questions: which model ran, how long it took, which tools executed, how many tokens were used, whether a tool failed, and how often edits were accepted. Full content capture is different. It may be appropriate in a lab, an isolated repro environment, or a short debugging window. It should not be casually pointed at a third-party telemetry backend unless that backend is approved to store source code, secrets-adjacent logs, customer snippets, and internal prompts.

This is where the read-only gh change and OTel story meet. Auto-approving a PR diff read may be reasonable. Exporting the full tool result from that diff to an observability vendor may not be. The same underlying action can be low mutation risk and high retention risk. A mature agent policy has to represent both.

Version drift is now model-access drift

The other small bullet in 1.0.46 is also worth more attention than it will get: Copilot CLI now warns when the installed CLI version is deprecated and “premium model access may be lost.” That is a dependency-management sentence wearing a product-support hat.

AI coding tools are no longer one extension and one model. They are a stack: CLI versions, IDE integrations, cloud workers, partner models, billing tiers, enterprise model policies, plugin systems, hooks, MCP servers, telemetry exporters, and local shells. When a CLI version drifts, the failure mode may not be a clean crash. It may be subtler: a preferred model disappears, a premium model stops working, agent behavior changes, a hook fires differently, or a background session fails in a way that looks like random flakiness.

Teams that are serious about agents should treat the CLI like any other developer dependency. Pin or standardize versions. Define update windows. Test model availability after upgrades. Keep a rollback path. Document which agent surfaces are approved for which repositories. If that sounds heavy for a CLI tool, that is the point: the CLI is no longer just a CLI tool. It is a runtime with repo authority.

The practical policy is boring, which is usually a good sign. Let agents auto-read the GitHub context they need, but write down which gh command families count as safe reads. Keep mutations behind explicit approval. Confirm whether private issues and PRs may enter model context. Enable OpenTelemetry first in a local collector, inspect the trace shape, then decide what belongs in a shared backend. Keep content capture off unless there is a specific reason, owner, time limit, and retention plan. Add Copilot CLI version checks to your dev-environment drift tooling.

Copilot CLI 1.0.46 will not be remembered as a major release. It should be remembered as a useful line in the sand. The future of coding-agent security is not “ask before everything.” That fails because humans are bad at repetitive low-context approval work. The future is precise authority classification: reads versus writes, disclosure versus mutation, metadata versus content, local traces versus exported evidence, current version versus deprecated runtime. Make approvals rare enough that they mean something, and make the agent’s quiet work observable enough that you can defend it later.

Sources: GitHub Copilot CLI v1.0.46 release, VS Code Copilot OpenTelemetry monitoring docs, OpenTelemetry GenAI semantic conventions