Why does a Cypress cy.origin() callback error when it calls cy.intercept() or cy.session()?

## Why the callback is a restricted environment Entering `cy.origin()` does not move your test into the other origin; it **starts a second Cypress instance there** and evaluates the stringified callback inside it. That instance drives the DOM of the secondary origin, but it is not the instance that owns the test as a whole. Commands whose effect is global to the test — the network route table, the cached session, the origin switch itself — therefore have no coherent meaning inside the callback, and Cypress refuses them outright rather than half-doing them. ## The commands that throw | Written inside the callback | What happens | Where it belongs | | --- | --- | --- | | `cy.intercept()` | throws, suggesting you use it outside the callback | before the navigation, on the primary origin | | `cy.session()` | throws, suggesting you use it outside the callback | around the block, in its setup callback | | `Cypress.session.*` methods | throw with a pointer to the session API docs | outside the block, at the top level | | a nested `cy.origin()` | throws as not currently supported | as the next top-level block | Everything else you would expect is available: `cy.visit()`, queries and actions, assertions, `cy.request()`, cookie and storage commands, custom commands you have loaded into that origin, and `Cypress.require()` for pulling in modules. ## Restructuring a flow that needs all three A bank statement app that hands a document off to a third-party viewer usually wants all of it in one test: a stubbed PDF response, a signed-in session, and commands running on the vendor's origin. The order that works: 1. **Interceptions first, on your own origin.** `cy.intercept()` is registered by the runner, not injected into the page, so a route declared before the navigation keeps matching once the browser is on the vendor's origin. Declaring it early also avoids the race where the request fires during the navigation itself. 2. **`cy.session()` on the outside.** Its setup callback may contain a `cy.origin()` block, which is how a redirect-based sign-in gets cached; the reverse nesting is rejected. Validation logic belongs in the session's own `validate` option, on the primary origin. 3. **One block per origin, in sequence.** If the flow passes through two vendors, write two `cy.origin()` calls one after the other. Between blocks you are back on the primary origin, which is the natural place to assert that the round trip landed where it should. ## Why aliases and state do not simply flow across The two instances share a test, not a memory. Practical consequences worth expecting: - the callback cannot see spec-level variables at all — data crosses only through the `args` option, as serializable values - anything the block yields must be serializable too, so assertions are usually cleanest kept inside it - the JavaScript execution context **is** reused between blocks for the same origin in one spec, which is why requiring custom commands once in a `before` hook makes them available to later blocks for that origin - that reuse does not extend to a different origin: a second vendor's block starts empty and needs its own `Cypress.require()` ## Reading the failure when it happens in CI These errors are explicit and name the command, so the trap is rarely the message itself — it is what a team does next. Two failure modes to watch for: - **Copying the flow instead of moving the command.** Faced with the interception error, people re-implement the stub as a fixture served by the vendor, or drop the stub entirely and let the test depend on a live third party. Moving one line out of the block is almost always the smaller change. - **Concluding the scenario is untestable.** The error says the command is unsupported *in the callback*, not that cross-origin stubbing is impossible. Interception, session caching and origin switching all work in the same test; they just each have a place. As of Cypress 16 each restriction is still an open issue rather than a permanent design decision, so the error messages link to the issue and invite a use case — worth knowing when you are deciding whether to build a workaround or wait.