Verified 2026-08-05 What was checked, and when — not a guarantee it is still true.
A large amount of Cowork's behaviour is served from the operator's side rather than shipped in the application, which means it can change with no new version, no release note, and no signal to your skill. Tool availability, prompt guidance, and some defaults are all in this category, and at least one of them has been observed changing mid-session. Write skills that detect capabilities at the moment of use and degrade in a stated way, rather than skills that assume a surface.
This is the single defensive pattern that survives everything else on this page. A skill that checks for the tool it needs, uses it if present, and says plainly what it could not do otherwise will keep working across lane changes, served-configuration flips, and version bumps. A skill that assumes a surface breaks silently on all three.
At least some served configuration is subscribed to rather than read once, so it can change while a session is running and the application reacts. A skill that reads a capability at the start of a long task and caches the answer can be wrong by the end of it.
From binary Can change without a version bump
The instructions a Cowork session runs with can be patched from the operator's side, including a mode that replaces the computed instructions wholesale rather than adding to them. So a model of the session prompt as 'the standard preset plus my additions' can be wrong at any time, with no local artifact changing. Depend on behaviour you can observe, not on text you expect to be present.
Caveat: The replace mode is the one that matters: it discards the computed instructions rather than appending to them.
Behaviour governed from the operator's side changes with no new version, no release note, and nothing observable locally. This has been directly observed: a capability that was off in one week's capture was on in the next, with no application update in between.
A meaningful part of what a session offers is decided on the operator's side at spawn time. Two sessions on the same application version can therefore present different tools and different defaults. Nothing about the installed version tells you what a given session will look like.
When something changes underneath you, the cost of diagnosis is dominated by not knowing what was assumed. A short stated list of dependencies — this needs a delivery tool, this needs shell access, this assumes files persist within the turn — turns a silent failure into an obvious one.
Caveat: Editorial guidance drawn from the failure modes on this site rather than a measurement.
Tool surfaces have changed across releases: names differ between runtimes, tools have been added and withdrawn, and which ones a session gets is decided when it starts. Name a tool only after checking it exists, and say what you will do if it does not.