# What can change without any version bump?

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.

### Detect capabilities at the moment you use them, and state a clear fallback when they are missing.

*Measured*

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.

### Do not assume configuration is fixed for the lifetime of a session.

*From binary*

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.

### Never write a skill that depends on the exact wording of the system prompt.

*From binary* · *Depends on server-side configuration — 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.

### Do not treat 'the version has not changed' as evidence that behaviour has not changed.

*Measured*

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.

### Assume tool availability and defaults are served to the session, not shipped in the application.

*Measured*

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.

### Write down which behaviours your skill depends on, in the skill itself.

*Inference*

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.

### Do not hardcode a tool name your skill merely hopes is present.

*Measured*

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.

## What is not established

- This site does not detect product changes. It records what was verified on a date against a build. Anything on this page can be true today and false tomorrow with nothing observable in between.

---

Consistent with the capture of 2026-08-05. Exact artifact versions and capture identity are on the current-state page. This documentation does not detect product changes.