Keeping a team current when the tools ship weekly

Keeping a team current with AI coding agents takes three routines: a rotating weekly release watch that sorts each change into break, default shift, candidate or noise; a graduation path that admits a new feature to the shared harness only after an evaluated trial; and team docs that stamp every tool fact with a version, channel and checked date.

Claude Code published 52 releases between 4 August and 25 September 2026, and Codex published 21 between 7 August and 26 September (npm registry, read 26 September 2026). In the same weeks, Codex removed codex exec --full-auto, Claude Code changed its default model, and Claude Code extended auto mode as the starting permission mode to every plan and provider on its latest channel. Your team’s AGENTS.md still names a removed flag, two engineers are on a different channel from CI, and the one person who noticed forwarded a changelog link. This page is for the tech lead who has to turn that into a routine that takes an hour a week.

What a release-watch routine gives your team

A rota with a 45-minute time box, a fixed source list per tool and a digest file the whole team reads.
A four-way triage table that says what to do with each change and by when.
A graduation path with a decision record that keeps untested features out of the shared harness.
Version pinning per tool, so developers and CI run the version you tested.
A date-stamping convention for team docs, plus two CI checks that fail when a fact is stale or a retired flag is still in use.
Three copy-paste prompts: triage the week’s releases, design a trial, and audit the harness for drift.

How fast do the agent tools change?

The five working days from 21 to 25 September 2026 show the pattern:

Date	Tool and version	Change	What it meant for a team
2026-09-22	Claude Code v2.1.280 (`latest`)	Claude Opus 5.5 became the default model on every paid plan	Cost and behaviour of every default session changed; evals run on the old default no longer describe the tool
2026-09-23	Claude Code v2.1.281 (`latest`)	`AGENTS.md` read when a project has no `CLAUDE.md`, now also on Bedrock, Google Cloud, Foundry and gateways	Claude Code sessions on those providers started reading instructions from a repository that has only `AGENTS.md`
2026-09-23	Codex CLI 0.156.1	GPT-6 Sol and GPT-6 Luna in the model picker	A cheaper option to trial for routine loops; no change for anyone who does nothing
2026-09-25	Claude Code v2.1.283 (`latest`)	Auto mode became the starting permission mode for interactive terminal and VS Code sessions on every plan and provider	Enterprise, API and cloud-provider sessions (Pro/Max/Team already since 14 August) started in auto mode unless settings disable it; `claude -p` and unsupported models still start in Manual

On 26 September 2026 the Claude Code stable channel was still v2.1.274 (npm dist-tags), so none of the three Claude Code rows applied to a team on stable. That split is the first thing the rota has to control. The models hub has the current model lineup and prices; this page links there rather than repeating them.

Set up the release-watch rota

The rota puts one named person on the watch each week, rotating through the team. Rotation spreads the knowledge and survives holidays.

Name the watcher and the slot. One engineer per week, in a fixed 45-minute slot on Monday morning, listed in the sprint plan as a ticket. Pair a junior with a senior for their first two turns.
Fix the source list. The watcher reads only the sources below, from the team’s pinned version to the newest release.
Triage every change into one of the four classes in the next section. Anything unclear goes in as a candidate with a question, not as noise.
Write the digest to docs/agents/release-watch/<year>-W<week>.md in the repository and open a pull request. The digest is short: breaks, default shifts, candidates, and a one-line count of noise.
Hand off. Breaks get an owner and a fix date before the slot ends. Candidates go to the tech lead, who picks at most one per fortnight for a trial.

Source	What to read	How to read it
Claude Code	Changelog and the channel versions	`npm view @anthropic-ai/claude-code dist-tags` in a terminal; `/release-notes` inside a session
Codex	GitHub releases for `openai/codex` and the bundled model catalog	`npm view @openai/codex version`; `codex features list`; `codex debug models --bundled`
Cursor	Cursor changelog	Browser; record the date you read up to, not a version
Models	Claude model deprecations and the Codex catalog above	Any retirement date inside the next 90 days is a break
Standards	MCP blog (2026-07-28 spec release post)	Only when a spec version lands; see what changed in MCP 2026-07-28

Read the week’s changes in each tool

Diff what each tool says about itself instead of trusting a summary: snapshot its surface when you pin a version, then diff the new version against it.

# Terminal: which versions are on each channel today
npm view @anthropic-ai/claude-code dist-tags

# Snapshot the flags and subcommands of the pinned version, then diff after an upgrade
claude --version > docs/agents/snapshots/claude-version.txt
claude --help > docs/agents/snapshots/claude-help.txt
# after upgrading on the watcher's machine only:
claude --help | diff docs/agents/snapshots/claude-help.txt - || true

Inside a session, /release-notes shows the notes for recent versions. Read every entry between the team’s pinned version and the target, not only the newest one — Claude Code ships roughly one release per day.

# Terminal: current release and the feature flags of this binary
npm view @openai/codex version
codex --version > docs/agents/snapshots/codex-version.txt
codex features list > docs/agents/snapshots/codex-features.txt
codex debug models --bundled | jq -r '.models[] | "\(.slug) \(.visibility)"' \
  > docs/agents/snapshots/codex-models.txt
# after upgrading on the watcher's machine only:
codex features list | diff docs/agents/snapshots/codex-features.txt - || true

codex features list prints every feature flag with its stage (under development, experimental, stable, deprecated or removed) and whether it is on. A flag that moves to stable is a candidate; a flag your config sets that moves to deprecated is logged as a break with next month’s date; one that moves to removed is a break now. The bundled catalog is not the whole story: since Codex CLI 0.154.0, fresh sessions follow the server’s model default unless you set one, so a model can change with no Codex release at all.

You are this week's release watcher for our team. Do not edit any file except
the digest you create.
1. Read our pinned versions from docs/agents/snapshots/claude-version.txt and
   docs/agents/snapshots/codex-version.txt.
2. Read the release notes from those versions up to the newest release:
   the Claude Code changelog at https://code.claude.com/docs/en/changelog.md
   and the GitHub releases of openai/codex. Run
   `npm view @anthropic-ai/claude-code dist-tags` and
   `npm view @openai/codex version` to get the newest versions.
3. Read our shared agent files: CLAUDE.md, AGENTS.md, .claude/settings.json,
   .codex/config.toml, .github/workflows/*.yml and docs/agents/*.md.
4. Classify every change as BREAK (removes or renames something our files
   use), DEFAULT SHIFT (changes a default model, permission mode, instruction
   file or pricing behaviour), CANDIDATE (a capability that could replace
   something we do by hand) or NOISE.
5. For each BREAK, quote the line in our files it affects, with file and line
   number, and the replacement named in the release notes.
6. Write docs/agents/release-watch/<ISO year>-W<ISO week>.md with sections
   Breaks, Default shifts, Candidates and a one-line noise count. Link each
   item to its release note. Mark anything you could not confirm from the
   release notes as "unconfirmed" instead of guessing.

Triage each change into one of four classes

The triage class decides the deadline. Without it, every change is equally urgent, which in practice means none of them is.

Class	Test	Action	Deadline and owner
Break	Removes or renames a flag, command, setting, model or file our harness uses	Fix pull request to the harness; add the old term to the retired-terms list	Before anyone upgrades; the watcher, reviewed by the tech lead
Default shift	Changes a default the team relies on: model, effort, permission mode, instruction file, sandbox	Run the team’s eval set on the new version before changing the pin; tell the team what changes for them	Before the pin moves; the tech lead decides
Candidate	New capability that could replace manual work or a home-grown script	Log it; the tech lead picks at most one per fortnight for a trial	Next trial slot; a volunteer
Noise	Fixes and features that touch nothing the team uses	Count it in the digest	None

Teams miss default shifts most, because nothing fails. When Codex made GPT-6 Astra its bundled default on 4 September 2026 (CLI 0.153.4), a team whose config.toml set no model got a different model the day they upgraded. Tests passed; cost and behaviour moved. Treat a default shift as a change the team makes on purpose: run the evals, then move the pin. The new-model playbook covers the model case in detail.

Graduate a feature into the shared harness

The shared harness is everything the team’s agents run inside: the instruction files, settings, hooks, skills, plugins and MCP servers that live in the repository or in managed policy. The harness overview describes the layers. A feature enters the harness only through the path below, because a change to the harness changes every engineer’s agent at once.

Observed. The watcher logs the feature as a candidate in the digest, with its release note and the minimum version it needs.
Trial. One volunteer uses the feature on one loop for at most two weeks, in a worktree or branch, with the team’s normal permission mode. Before starting, they write down the hypothesis and the eval: which recent tickets or katas they will re-run, and what result counts as better. The eval result decides, not the volunteer’s impression.
Harness pull request. If the trial passes, the volunteer opens one pull request that adds the feature to the shared harness: a line in CLAUDE.md or AGENTS.md, a key in .claude/settings.json or .codex/config.toml, a skill, or a plugin in the team marketplace. The pull request carries the decision record below, a version gate (“needs Claude Code v2.1.283 or later, latest channel”) and a one-line rollback. CODEOWNERS on the harness paths routes it to the tech lead.
Teach. The volunteer spends ten minutes on it in the next review-to-learn session from upskilling a team for agentic engineering. A feature that nobody else knows how to use did not graduate.
Review at 90 days. The decision record has a review date. On that date the owner keeps, changes or retires the feature, and says which in the digest.

Keep the decision record in the pull request description and in docs/agents/decisions/:

feature: "GPT-6 Sol for the dependency-bump loop in Codex"
observed_in: "docs/agents/release-watch/2026-W39.md"
needs: "Codex CLI 0.156.1 or later"
hypothesis: "Sol passes the same dependency-bump evals as the default model at lower usage"
trial:
  owner: "m.wisniewska"
  loop: "weekly dependency bumps, services/billing"
  window: "2026-09-28 to 2026-10-09"
  eval: "re-run the last 8 merged dependency-bump tickets; hidden tests must pass on all 8"
  result: "8 of 8 passed; review findings unchanged"   # filled in at the end of the trial
decision: adopt            # adopt | reject | extend-trial
harness_change: ".github/workflows/deps.yml: codex exec -m gpt-6-sol"
rollback: "remove -m gpt-6-sol from the deps job"
approved_by: "tech-lead-billing"
review_on: 2027-01-09

Our release watch logged this candidate feature:
<paste the digest entry and the release-note link>
Design a two-week trial that a single volunteer can run on one loop.
1. Name the loop in this repository where the feature is most likely to
   help, based on git history of the last 90 days. Prefer a loop with tests
   that decide success.
2. Write a falsifiable hypothesis in one sentence.
3. Pick 5 to 8 recently merged tickets on that loop to re-run as the eval,
   list them by pull request number, and say what result counts as better,
   the same, or worse. Use test outcomes, review findings and rework, not
   impressions.
4. List the settings or files the trial changes, and confirm none of them is
   shared by the rest of the team.
5. Fill in a decision record in the format of
   docs/agents/decisions/*.yaml, leaving result and decision empty.
Do not change the team's permission mode, sandbox or managed settings for
the trial.

A feature the team cannot turn off in one line does not enter the harness at all. The tooling roadmap is where the tech lead’s rejected and extended trials feed the organisation’s capability bets.

Pin versions so the team and CI run what you tested

Graduation means little if half the team runs a different version. Pin the version the eval set passed on, everywhere, and move the pin as a deliberate change.

Claude Code has two release channels. latest gets every release; stable is “typically about a week behind” and skips releases with major regressions (Claude Code setup docs, checked 26 September 2026). Choose one for the whole team.

{
  "autoUpdatesChannel": "stable",
  "requiredMinimumVersion": "2.1.274"
}

Put this in managed settings, not in each person’s user settings, so it applies to everyone; enforcing one policy across every coding agent covers delivery. The settings schema in Claude Code 2.1.283 describes requiredMinimumVersion and requiredMaximumVersion as enforced only from managed settings: a version outside the range exits at startup with instructions to install an approved one. requiredMinimumVersion only stops machines that are behind; add requiredMaximumVersion as well if you want auto-updates to stop at the version your evals passed, which makes every pin move a managed-settings change.

On a single machine, claude install stable or claude install 2.1.274 installs a channel or an exact version. In CI, install the exact version the team pinned, for example npm install -g @anthropic-ai/claude-code@2.1.274 for the stable pin above, and pin the model with the model setting if your evals depend on it.

Codex has no stable channel: the npm latest tag was 0.157.1 on 26 September 2026, and prereleases go out under a separate alpha tag (0.159.0-alpha.9 that day), which nobody on the team should install. Pin the exact version on developer machines and in CI, and move it only after the eval set passes on the new one:

# Terminal and CI: install the version the team tested
npm install -g @openai/codex@0.157.1
codex --version   # codex-cli 0.157.1

codex update moves a machine to the newest version, so it belongs to the watcher’s machine, not the team’s. Because fresh sessions follow the server’s model default unless you set one (CLI 0.154.0 and later), set model in the team’s .codex/config.toml or in a named profile for any loop whose evals depend on a specific model. Admin constraints in requirements.toml control approval policies, sandboxes and MCP servers; we found no minimum- or maximum-version setting in the Codex 0.157.1 binary (checked 26 September 2026), so enforce the version through your install tooling.

Cursor updates itself, and this page could not verify a Cursor setting for pinning or delaying updates (cursor.com unreachable on 26 September 2026), so treat Cursor as running latest: default shifts in Cursor go straight to the eval step. Scripted use through @cursor/sdk (1.0.32 on npm on 26 September 2026) is pinned in package.json.

Date-stamp the team’s agent docs the way this site does

This site keeps every model name, price, default and flag in one facts sheet, each row with its source and checked date. Four of its rules transfer directly to a team’s own agent docs:

Every fact carries a checked date and a source. A fact is true on its checked date only.
Every version-gated claim names its version and channel. Write “from v2.1.283 (latest channel)”, never “Claude Code now…”.
Every negative claim carries the version it was checked against. Write “Codex CLI 0.157.1 has no --full-auto flag (checked 26 September 2026)”, never “Codex has no --full-auto”.
Retired terms go on a never-write list with what replaces them, so a stale instruction is caught by a machine, not by a confused new hire.

In a team repository, rules 1 to 3 become one table and rule 4 becomes one text file. Keep the table in docs/agents/tool-facts.md:

| Fact | Tool and version | Source | Checked | Re-check by |
| --- | --- | --- | --- | --- |
| Default model is Claude Opus 5.5 on paid plans and the Anthropic API (not Foundry) | Claude Code v2.1.280+ (`latest`) | https://code.claude.com/docs/en/model-config.md | 2026-09-26 | 2026-10-26 |
| `-a` accepts only `on-request` and `never` | Codex CLI 0.157.1 | `codex --help` | 2026-09-26 | 2026-10-26 |
| Team pin: Claude Code `stable`, Codex 0.157.1 | Team decision | docs/agents/decisions/ | 2026-09-26 | 2026-10-26 |

Keep the never-write list in docs/agents/retired-terms.txt, one extended regular expression per line, with a comment saying what replaces it:

# One extended regex per line. The comment above each says what replaces it,
# since which version, and when the team checked it.
# Codex: `codex exec --full-auto` removed in 0.147.0 (2026-08-07); use a permission profile.
--full-auto
# Codex: cannot run as an MCP server since 0.154.0 (2026-09-09); use codex exec or the Codex SDK.
codex mcp-server
# Codex: -a accepts only on-request and never (checked on 0.157.1, 2026-09-26).
(-a|--ask-for-approval)[ =](on-failure|untrusted)
# Claude Code: /ultraplan left the command reference in v2.1.222; use /plan.
/ultraplan
# Cursor: Background Agents are now Cloud Agents (name checked 2026-08-28).
Background Agents?

Two scripts turn both files into gates. The first fails when a shared agent file still uses a retired term:

#!/usr/bin/env bash
# Fails when a shared agent file still uses a term the team has retired.
set -euo pipefail
terms=docs/agents/retired-terms.txt
mapfile -t files < <(git ls-files -- '*CLAUDE.md' '*AGENTS.md' '.claude/*' '.codex/*' '.cursor/*' '.github/workflows/*')
[ "${#files[@]}" -eq 0 ] && exit 0
if grep -nE -f <(grep -vE '^[[:space:]]*(#|$)' "$terms") -- "${files[@]}"; then
  echo "Retired agent terms found. See $terms for what replaces each one." >&2
  exit 1
fi
echo "No retired agent terms in ${#files[@]} shared agent files."

The second fails when a fact is past its re-check date:

// Fails when a row in docs/agents/tool-facts.md is past its re-check date.
import { readFileSync } from 'node:fs';

const today = new Date().toISOString().slice(0, 10);
const rows = readFileSync('docs/agents/tool-facts.md', 'utf8')
  .split('\n')
  .filter((line) => /^\|.*\|\s*\d{4}-\d{2}-\d{2}\s*\|\s*$/.test(line));

const stale = rows.filter((line) => {
  const cells = line.split('|').map((c) => c.trim()).filter(Boolean);
  return cells.at(-1) < today; // last column: Re-check by (ISO dates compare as strings)
});

for (const line of stale) console.error(`STALE: ${line}`);
console.log(`${rows.length} dated facts, ${stale.length} past their re-check date.`);
process.exit(stale.length ? 1 : 0);

Run both on every pull request and once a week before the watch, with a read-only token:

name: harness-freshness
on:
  pull_request:
  schedule:
    - cron: '17 6 * * 1' # Mondays 06:17 UTC, before the release watch
permissions:
  contents: read
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - run: bash scripts/check-harness-drift.sh
      - run: node scripts/check-tool-facts.mjs

The scheduled run matters most: a fact expires on a date, not on a commit, so the Monday failure lands in the watcher’s slot.

Audit our shared agent files for undated or stale tool facts. Do not change
any file; report only.
Files: CLAUDE.md, AGENTS.md (all of them), .claude/settings.json,
.codex/config.toml, docs/agents/*.md.
1. List every sentence that states a tool fact: a model name, a default, a
   flag, a command, a setting key, a version or a price.
2. For each, say whether it has a version, a release channel (for Claude
   Code) and a checked date nearby, and whether it appears in
   docs/agents/tool-facts.md.
3. Flag every negative claim ("X has no Y", "X does not support Y") that
   does not name the version it was checked against.
4. Run `claude --version`, `codex --version`, `claude --help` and
   `codex --help`, and flag any flag or command in our files that does not
   appear in the help output of the installed version.
5. Output a Markdown table: file, line, fact, missing stamp, suggested
   tool-facts.md row. Mark anything you could not check as "unchecked".

How do you know the release watch is working?

These measures show whether the routine changes anything; each has an owner.

Measure	Definition	Target and owner
Break lead time	Days from a break’s release date to the merged harness fix, for releases newer than the team’s pin	Fixed before the pin moves, every time; the watcher of that week
Unplanned breaks	Breaks the team discovered from a failure instead of from the digest	Zero per quarter; reviewed by the tech lead in the retrospective
Drift gate failures	Failures of `check-harness-drift.sh` and `check-tool-facts.mjs` on the Monday run	Fixed within the watch slot; the watcher
Trial yield	Share of trials in the quarter that ended in a decision record with an eval result	Every trial; one that ends without a result is a failed trial, not a pass
Pin skew	People or CI jobs on a Claude Code channel or Codex version other than the team pin, from `claude --version` and `codex --version` output collected in the watch	Zero; the tech lead

The sign-offs are fixed. The watcher signs the digest. The tech lead approves every harness pull request, every pin move and every default-shift decision. The platform owner or CTO approves anything that changes managed policy for more than one team; who owns the harness, the gates and the evals sets that boundary.

How does this answer the Tech Lead Scorecard’s question on keeping current?

Question 21 of the Tech Lead Scorecard asks how you keep the team current as tools change, and its top answer is “owned radar + sandbox + rollout decisions”. On this page the rota is the owned radar, the two-week trial is the sandbox, and the triage classes, pins and decision records are the rollout decisions.

What breaks when a team tries to keep current

The watch becomes changelog forwarding. The watcher pastes links into the team channel, and nobody acts on them. To recover, require the digest file in a pull request and require an owner and a date for every break before the slot ends.

Auto-update breaks CI on a Tuesday. A CI job installs the newest CLI, a flag it uses was removed, and every agent job fails. To recover, pin an exact version in CI, add the flag to retired-terms.txt, and move the CI pin only in the same pull request that moves the team pin.

Half the team is on a different channel. Some engineers installed from the latest channel and some through a package manager that tracks stable. On 26 September 2026 that meant one group had Opus 5.5 as the default and read AGENTS.md, while the other ran Opus 5 or Sonnet 5 and ignored AGENTS.md; on Enterprise, API and cloud-provider seats only the latest group started in auto mode. Review findings stop being comparable. To recover, set autoUpdatesChannel and requiredMinimumVersion in managed settings and check pin skew weekly.

A default shift goes unnoticed. Nothing fails, but cost or behaviour changes after an upgrade or a server-side model default change. To recover, re-run the eval set on every pin move, and set the model explicitly for any loop whose evals depend on it.

An enthusiast merges a feature straight into the shared harness. A new hook or skill lands in .claude/ because it worked once for one person. To recover, add CODEOWNERS on the harness paths, revert to the last approved state, and send the feature through a trial. Shared hooks governance and shared skills cover the review bar for each type.

The rota lapses. Two holidays and a deadline later, nobody has read a changelog for a month. To recover, keep the watch as a sprint ticket with a named owner, let the Monday check-tool-facts.mjs run fail loudly, and catch up by reading from the pinned version forward rather than skimming the last week.

Where to go next with keeping current

Upskilling a team for agentic engineering The curriculum and review-to-learn sessions where a graduated feature is taught.

Shared agent rules: one core, tested adapters How the instruction files a graduation changes are structured and tested.

Enforcing one policy across every coding agent Managed settings that carry the team's version pin and model choices.

Adopting a new model without breaking your loops The eval-first procedure for the default shifts the watch finds.

Knowledge sharing: version evidence, not tricks Where trial results and decision records live so they outlast the person who ran them.

Tech lead track The reading path this page belongs to.

Frequently asked questions

How does a team keep up with AI coding tools that release every week?

Give one person a rotating, time-boxed weekly release watch. They read each tool's changelog since the team's pinned version, sort every change into break, default shift, candidate or noise, and write a short digest. Breaks are fixed that week; candidates go through a trial before they reach the shared harness.

How does a new agent feature get into the team's shared setup?

Through five stages: observed in the digest, trialled by one volunteer on one loop against the team's own eval set, merged into the shared harness in a reviewed pull request with a version gate and a rollback line, taught in the next review session, and reviewed again after 90 days.

Should the team run the stable or latest channel of Claude Code?

Pick one and pin it for everyone, including CI. On 26 September 2026 the latest channel was v2.1.283 and stable was v2.1.274, and several behaviours (Opus 5.5 as the default, reading AGENTS.md, and auto mode as the starting mode on Enterprise, API and cloud-provider seats) existed only on latest. A mixed team runs two different agents.

How do you stop team agent docs from going stale?

Stamp every tool fact with the version, channel and date it was checked, give each row a re-check date, and run two CI checks: one fails when a fact is past its re-check date, the other fails when a shared agent file still uses a flag or command the team has retired.