---
title: "Verify candidate configuration stays inside the sandbox"
description: "Inspect a candidate release in an owned sandbox to confirm displayed environment identity and a harmless write both resolve to the intended isolated target."
canonical_url: "https://vostride.com/agent-library/release-regression/configuration-target-isolation.md"
md_url: "https://vostride.com/agent-library/release-regression/configuration-target-isolation.md"
content_kind: "recipe"
topic: "release-regression"
---

# Verify candidate configuration stays inside the sandbox

Inspect a candidate release in an owned sandbox to confirm displayed environment identity and a harmless write both resolve to the intended isolated target.

## Risk

A page can display a staging banner while its write endpoint points elsewhere. Use a harmless uniquely marked record and independently inspect the configured sandbox ledger; never probe production by creating a matching control write.

## Fixtures

- An owned candidate sandbox with independently verified allowed API origin and a disposable test account restricted to that environment.
- A harmless note workflow and a unique run marker, with network or request tracing configured through the existing approved test infrastructure.
- A read-only sandbox ledger plus an external configuration manifest listing the intended backend and environment identifiers.

## Steps

1. Open the candidate app and verify its environment indicator and account workspace match the sandbox configuration manifest.
2. Create the uniquely marked harmless note and verify the reopened detail shows the intended content and sandbox workspace.
3. Inspect the approved request trace and verify the write destination belongs to the configured sandbox origin and carries the expected environment routing metadata.
4. Read the independent sandbox ledger and verify exactly one note with the run marker and correct workspace; confirm all observed write destinations remained within the allowed fixture target.

## Expected results

- The displayed environment and actual write destination agree.
- The new record exists in the intended sandbox workspace with exact fixture content.
- Observed write requests remain confined to the independently allowed target configuration.

## False-pass traps

- A staging banner alone can conceal a production API base URL.
- Finding a note in local optimistic state does not prove which backend accepted it.

## Cleanup

- Delete the harmless sandbox note and retain a sanitized trace containing no credentials or private payloads.

## Use with agent-qa

Adapt this test design to your application's acceptance criteria and configured target using the [recipe execution guide](/agent-library/software-factory/turn-a-recipe-into-an-agent-qa-test.md). External fixture setup and non-UI checks require your own supported hooks or test tooling. Validate the authored test, execute it, and inspect the completed evidence; this recipe is not a recorded test result.

## References

- [agent-qa first test](/docs/agent-qa/guides/first-test.md)
- [agent-qa hooks](/docs/agent-qa/guides/hooks.md)
- [agent-qa test](/docs/agent-qa/configuration/test.md)

- [Release regression QA recipes](/agent-library/release-regression.md)
- [Software factory QA library](/agent-library.md)