-
The tag moved after the review.
On 14 October 2026 GitHub
put Actions workflow
dependency lockfiles in
public preview for GitHub
Enterprise Cloud and
Enterprise Cloud with data
residency. Tags and branches
can move after you review a
workflow, so a later run
might execute different
code. A lockfile lets you
keep those references in the
workflow while running the
exact commits you locked. If
an action is compromised, a
moved tag or branch can
introduce malicious code
without a change to your
repository. Locking does not
decide whether the
dependency is safe. Review
it before you lock it.
The
gh actions-lock
extension writes
.github/workflows/actions.lock
with reviewable commits for
actions, their transitive
dependencies, and reusable
workflows. You can onboard
workflows one at a time.
Once a workflow is
onboarded, it must have
lockfile entries for its
dependencies, and Actions
runs the recorded commits
even if a tag or branch
moves. You can check that
the lockfile is current
without modifying files,
including from CI.
Enterprise, organization,
and repository admins can
require lockfiles. When
Dependabot opens a version
update for an action in an
already-onboarded workflow,
it regenerates the matching
lockfile entry in the same
pull request.
A tag in the YAML is a
label. The run should be the
commit you locked, and the
lock is not a substitute for
reading the dependency
first.
Source:
GitHub Changelog — Actions workflow lockfiles in public preview
-
A cached policy is not a current policy.
On 13 October 2026 GitHub
let enterprise admins
require supported Copilot
clients to fetch current
server-managed settings at
startup instead of trusting
a cached policy. Set
forceRemoteSettingsRefresh
to true through
server-managed,
MDM-managed, or file-based
settings when a policy
change must take effect
before Copilot starts. It is
supported in Copilot CLI, VS
Code, and the Copilot app.
MDM and file-based delivery
can require freshness before
the client signs in the
first time. A server-managed
value starts requiring
refreshes on later startups,
after the client has
received it once. While the
setting is on, a cached
response cannot satisfy
freshness. If the client
cannot confirm current
policy, it fails closed
rather than running on a
stale or unconfirmed policy.
Without the setting, clients
keep the normal cache, which
starts faster and survives a
brief outage. GitHub is also
adding minimum client
versions to governance keys,
starting with the sandbox
key, so a user pinned to an
older client has to update
before Copilot will run when
that key is in managed
settings.
A policy you published this
morning is not the policy a
laptop cached last week. If
the change has to win before
the agent starts, make a
stale cache insufficient,
and refuse to start when the
fresh read fails.
Source:
GitHub Changelog — Enterprise managed settings enforcement updates
-
The resume line was a shell command.
Claude Code 2.1.299, dated
14 October 2026, closes
several places where a name,
a hop, or a missing answer
became an execution. The
resume command printed at
exit now names the session
by its ID, not its name, so
nothing in a session name
can run when the line is
pasted. Requests to
claude.ai’s connector proxy
and to Anthropic-hosted MCP
servers no longer follow
HTTP redirects. Redirects by
a connector’s own server are
unaffected. MCP requests in
cloud and self-hosted runner
sessions no longer follow
redirects from the session’s
MCP proxy.
A plugin hook that can block
an action is now refused,
not let through, when the
hook cannot be handed that
action or cannot hand back
an answer. If the tool
already ran, its result is
withheld.
UserPromptSubmit
hooks run before a skill or
custom slash command
expands, so a hook that
blocks the prompt also stops
its embedded shell commands.
CLAUDE_CODE_DISABLE_FILE_MENTIONS
is optional, and it changes
what an
@ mention
sends: paths, for the model
to read with its file tools,
not the files’ contents.
A label you did not mean to
execute should not become
the run. Deny when the check
cannot speak. Do not follow
a hop you did not pin.
Source:
Claude Code changelog — 2.1.299
-
The clone was the bottleneck.
On 13 October 2026 Anthropic
published how source control
became their biggest
development bottleneck once
merges grew more than
tenfold. In May they
averaged about 2,500 code
changes merged per day. By
September they merged over
30,000 per day. Coding, they
write, is no longer the
bottleneck. Claude iterates
on research loops,
micro-optimizes programs,
and builds services. The
strain showed up in
infrastructure sized for
humans: source control,
builds, and CI.
They built Scion, an
in-house version control
system, and migrated the
monorepo off git in five
months. Main-branch history
alone is almost 100 GB.
A compressed working copy is
over 25 GB. They do on
the order of 25 million code
checkouts a day for CI,
before developer
environments, agent
sandboxes, and research
jobs. Fetched naively, that
would be over 600 PB of
git traffic a day. At peak
they ran several hundred
internal git mirrors. Scion
assumes those clients are
online. The server creates
commits, merges, and
rebases, so there is nothing
to push, and the cost of a
commit scales with the size
of the change, not the size
of the repo. A changeset
stores the files that
changed relative to its
first parent, plus
content-addressed blobs. A
CI job that needs a diff can
ask the server instead of
checking the tree out. They
are explicit that most
organizations will not have
this problem immediately,
and that teams using AI
coding tools will hit the
same pressure points.
If the clients are always
online, a full clone is a
copy of a fact the server
could have returned. Ask for
the diff. Do not ship the
repository to every job that
only needed one answer.
Source:
Anthropic Engineering — Redesigning source control at Anthropic