Product news: Claude Code 2.1.236 clarifies default models and cross-session coordination

Anthropic's Claude Code 2.1.236 release adds two coordination controls with direct relevance to teaching teams and research software projects. The ANTHROPIC_DEFAULT_MODEL environment variable can set the model that new sessions begin with, while a selection made through the model command can still override and persist across restarts. A notify_when_idle option for cross-session SendMessage can ask another local session to alert the sender when it becomes idle. The release also includes reliability and usability fixes.

A default model is an operational starting point, not a reliable record of what completed a task. A user may override it, an organization may apply policy, a service may route a request differently, or a resumed session may retain an earlier choice. Models can differ in capability, speed, cost, context limits, safety behavior, and availability. In assessed or reproducible work, teams should capture the actual model and relevant settings at execution time rather than infer them from an environment configuration.

Cross-session notification solves a different problem: knowing when another strand of work may be ready for attention. It can reduce manual polling when several bounded tasks are coordinated. Yet an idle signal does not mean a task passed its acceptance criteria. A session may be idle because it completed, failed, reached an ambiguity, or awaits a review decision. The sender still needs the artifact, test output, limitations, and a clear status. Notification is transport metadata, not completion evidence.

These distinctions are teachable in project-based learning. A student team can assign one session to implement a function and another to review tests. Before work begins, the team records the task owner, chosen model, permitted files, required tests, and handoff format. When an idle notification arrives, the receiving student checks the commit or diff, reruns tests in a clean context, and records acceptance or rejection. If a model was overridden, the log is updated. The exercise turns orchestration into visible academic practice rather than invisible automation.

Institutional environments add governance questions. Administrators should decide where defaults are set, who may override them, whether premium routes need cost approval, and how sensitive course or research data moves between sessions. Cross-session messages should carry the minimum context necessary. They should not become a path for copying confidential records, credentials, or unverified assumptions into unrelated work. Shared machines also require clear ownership and retention rules.

For AIEDHK, the update supports a useful separation among configuration, coordination, and verification. Configuration chooses a starting model. Coordination helps sessions exchange status. Verification determines whether the educational or technical goal was met. A defensible workflow records all three and keeps a human accountable for acceptance. The release can make multi-session work smoother, but trustworthy learning and research still require an exact task contract, observable evidence, independent checks, and a clear final decision. This record should remain understandable to a teacher or reviewer who did not participate in the original sessions and cannot rely on their hidden context.