Some tool definitions and highlighting tables are built at startup instead of on first use.
What's wrong with this entry?
Several internals that were previously constructed lazily, on the first call that needed them, are now plain top-level objects built when their module loads. This covers the Read and TaskList tool definitions, the syntax-highlighting language registry, and the filesystem adapter that registry uses. Nothing observable changes: schemas, descriptions and highlighting behaviour are identical, only the moment of construction moved earlier.
- Read and TaskList tool definitions no longer go through deferred initialisation; their JSON schemas and descriptions are byte-for-byte unchanged.
- The highlight language registry, including entries such as the one for VBScript embedded in HTML, is now a top-level object rather than being assembled on the first highlighting call.
- The filesystem adapter backing the highlighter is constructed at load in the same way.
- No flag, setting or environment variable gates this; there is no lazy path left to fall back to.
- Read still reports when a whole-file read was auto-paginated because it exceeded the token cap, meaning the returned content is only a partial first page.
True when a whole-file read was auto-paginated because it exceeded the token cap (the content is a partial first page)., "vbscript-html":
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.234
Startup prefetch failures no longer surface
Both mention startup
-
v2.1.239
Deleted working directories are detected at startup and handled during hooks
Both mention startup
-
v2.1.242
A socket path taken by another running Claude Code no longer breaks startup
Both mention startup