update_yaml_file did a read-modify-write with open(filename, 'w'), which
truncates in place. Two concurrent cycode processes both truncated to zero
and each kept its own file offset, so whichever wrote fewer bytes left the
longer writer's tail behind past its end. The boundary is a raw byte offset,
so it landed mid-token and produced an unparseable credentials.yaml.

The size gap is built in: refresh_access_token persists a ~900 char JWT while
invalidate_access_token persists nulls. Parallel AI guardrails hook
invocations put both on the same file at the same time.

Recovery was impossible because update_yaml_file reads before it writes, so
cycode auth raised the ScannerError before it could write the repair. The
hook then respawned cycode auth, forever.

Write to a sibling temp file and os.replace it into place, so a reader never
observes a partial file and a short write cannot leave a long tail. On a
YAMLError, move the file aside as <name>.corrupt-<n> and carry on with an
empty config; this sits at the single choke point every command goes through,
so cycode auth can now repair the machine on its own.

Concurrent updates can still lose each other's keys, which is accepted: the
losing writer's credentials are still valid ones.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

Both new tests were coupled to the runner environment rather than to the
behaviour under test, and failed across the tests_full matrix.

fs.chmod cannot express a read-only filesystem on CI, which runs as root:
root passes every permission check, so the write went through and the test
read back 'updated' instead of 'original'. Patch os.access for the path under
test instead, which is what the code actually branches on.

The concurrency test spawned real writer processes, which meant writing a
script to disk to keep multiprocessing spawn from re-importing __main__ (the
pytest entry point) and to work on windows-latest. Dropped in favour of
injecting a failure mid-write: the existing file has to survive untouched,
which truncating it up front could never guarantee. Same class of bug, no
subprocesses, and it still fails against the pre-fix code.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>