[zongqichen]

Why

Application tests could read the caller's global Cloud Foundry configuration during automatic workspace setup. Isolate the test process before any application entry point runs.

What changed

• Give the application test process a temporary user home and CFS state.
• Clear inherited execution selectors and retain separate homes for common test fixtures.
• Add a subprocess regression that covers direct global-home reads and named commands.

Scope

• Covers application tests and their environment setup.
• Production login inheritance and shim behavior stay unchanged.

Blast Radius

The change affects test processes only. Existing synthetic import fixtures still exercise global-login inheritance.

Verification

• The regression fails before the fix and passes after it. A filesystem probe confirms that the synthetic caller configuration is no longer opened or read.
• make check, make release-check, make security, and make smoke pass with isolated state and the official CF CLI.

Closes #54.

[zongqichen]

PASS for PR #55 at d9051fe90ba2c694019fd488fdd582134860a11e against base 75986e5. I did not author the change.

I compiled parent 89a7d9c and head with Go 1.27.3. The direct-entry regression failed on the parent because it saw the synthetic caller target and inherited external CF_HOME. The same test passed on head under hostile inherited HOME, USERPROFILE, CF_HOME, CF_TRACE, and cfs mode variables.

The independent inotify canary reproduced synthetic caller .cf/config.json access on both the supplied baseline and the compiled parent. A newly compiled head binary neither opened nor read that file. All 12 explicit synthetic import and seed fixtures passed. The full compiled internal/app suite passed under hostile inherited variables. A dedicated TMPDIR was empty after the regression, and the untagged app tests cross-compiled for Windows amd64.

No production Go source changed. I found no cleanup, portability, or behavior concern.