Short answer: none. Post-Recovery redirects aren’t supported; recovery always transitions to Settings, and after saving the new password you must rely on the Settings flow’s redirect configuration (or a return_to carried from Recovery) rather than sending the user “back to login.” The docs explicitly state: “The Post-Recovery redirect isn't supported and will automatically redirect the user to the Settings UI URL. Use the Post-Settings redirect for Post-Recovery flows.” ([Browser redirects and flow completion](https://www.ory.sh/docs/concepts/redirects#redirect-flows)). What you can do: - Configure the Settings flow redirect (default or per-method) to your login page if that’s desired after password change ([HTTP redirection configuration](https://www.ory.sh/docs/kratos/concepts/browser-redirect-flow-completion#redirection), [Redirect flows — Settings section](https://www.ory.sh/docs/concepts/redirects#redirect-flows)). - Or pass a return_to when starting Recovery; it will persist to Settings and be used after the Settings submit ([Advanced integration — Advanced redirects](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-advanced-integration)). Note: Several issues track limitations/bugs around Recovery redirects and return_to, especially with 2FA, so behavior may vary depending on configuration ([Recovery flow redirect after success not working](https://github.com/ory/kratos/issues/2371), [Recovery with 2FA does not respect return_to](https://github.com/ory/network/issues/222), [Redirect to /ui/settings not allowed with 2FA](https://github.com/ory/network/issues/363)).

Two things can make the Recovery flow have a non-empty return_to: 1) You explicitly pass return_to when initializing the Recovery flow - The browser init endpoint supports ?return_to=… and will store it on the flow. Your UI can (and should) forward the same return_to when you create the recovery flow if you want it to persist (e.g., from a login-initiated redirect) ([API ref: createBrowserRecoveryFlow](https://raw.githubusercontent.com/ory/docs/master/docs/reference/api.json)). - In BYO UI examples, the recovery route reads req.query.return_to and appends it when redirecting to /self-service/recovery/browser (so the flow gets a non-empty return_to) ([Create recovery flow example](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-basic-integration#create-recovery-flow)). 2) You propagate return_to across flows yourself - return_to does not automatically persist between different flows (e.g., login -> registration). Your app must read flow.return_to from the current flow and pass it when initializing the next flow. An exception: recovery -> settings automatically carries it over. Thus, if “Forgot password” starts recovery with return_to set, it will be available after the settings submit ([Advanced redirects](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-advanced-integration)). If you don’t pass return_to when starting recovery, it will be empty. There’s no implicit population from Hydra/OAuth unless your UI retrieves data (e.g., via login_challenge) and sets return_to accordingly; this was discussed for Account Experience but not automatic in Kratos itself ([Account Experience and redirect_uri discussion](https://github.com/ory/network/issues/264)).

Short answer: the Account Experience can inject a return target based on the OAuth2 login_challenge, but this isn’t guaranteed and differs across projects/configs. In Kratos itself, return_to is only set if you pass it when initializing the flow; there’s no automatic population from Hydra. The behavior you see (Forgot password link having a non-empty, absolute URL using the project slug domain) is consistent with the Account Experience deriving a target from the OAuth2 request (e.g., request_url/redirect_uri) for some projects, while others don’t perform that derivation. What the docs and issues say: - Kratos redirects: return_to is honored only if provided when initializing browser flows and must be whitelisted (allowed_return_urls). Otherwise it stays empty. Post-recovery isn’t supported; recovery transitions to Settings, and you must use Settings redirects or a propagated return_to (from Recovery) to control where the user ends up after saving (password) (Browser redirects and flow completion; HTTP redirection config) ([Redirect flows](https://www.ory.sh/docs/concepts/redirects#redirect-flows), [HTTP redirection configuration](https://www.ory.sh/docs/kratos/concepts/browser-redirect-flow-completion#redirection)). - Hydra interop: Multiple discussions note that Account Experience could/should map the OAuth2 redirect_uri (or request_url via login_challenge) into the login return_to, but this is not inherent to Kratos. It was discussed as an enhancement; implementations and edge cases were tracked in issues, not guaranteed across all projects (“Account Experience should transfer redirect_uri to login return_to”) ([Issue 264](https://github.com/ory/network/issues/264)). In that thread, the suggested behavior is to return users to the original /oauth2/auth request or use redirect_uri, but it’s acknowledged sessions/expiry and chained flows complicate it ([Issue 264](https://github.com/ory/network/issues/264)). - Multi-domain/custom-domain nuances: where absolute vs relative URLs are used can depend on project/domain configuration. There are known limitations when multiple custom domains are present; redirects may fall back to full URLs tied to the project slug domain instead of a custom domain, and per-domain redirect config is not yet generally available ([Issue 374](https://github.com/ory/network/issues/374), [Issue 218](https://github.com/ory/network/issues/218)). Social sign-in also has a base_redirect_uri setting that changes which hostname appears during OIDC flows; older projects defaulted to the slug.projects.oryapis.com host unless reconfigured ([Redirect URL for social sign-in](https://www.ory.sh/docs/identities/sign-in/social-sign-in/redirect-url), [Troubleshooting: oryapis.com as redirect URI](https://www.ory.sh/docs/troubleshooting/troubleshooting-social-sign-in#oryapiscom-doesnt-work-as-authorized-redirect-uri)). Why Production vs Development differ: - Your Production project’s Account Experience likely derives and injects a return target (using login_challenge → Hydra request_url/redirect_uri) into the “Forgot password” link, producing a non-empty absolute URL, and it may default to the slug.projects.oryapis.com host if custom-domain redirect base or per-domain mapping isn’t configured for that flow ([Issue 264](https://github.com/ory/network/issues/264), [Issue 374](https://github.com/ory/network/issues/374)). - Your Development project likely does not have this derivation active or lacks equivalent configuration, so the login flow’s return_to remains empty and the “Forgot password” link has no return_to. What to check/change: - Ensure you initialize flows with ?return_to=… when you want deterministic behavior; whitelist domains via selfservice.allowed_return_urls ([HTTP redirection configuration](https://www.ory.sh/docs/kratos/concepts/browser-redirect-flow-completion#redirection)). - In Ory Console, review Branding → UI URLs and Account Experience → Browser redirects. If you use multiple custom domains, note current limitations; prefer explicit full URLs or pass return_to dynamically per request until per-domain redirects are available ([Issue 374](https://github.com/ory/network/issues/374)). - If OIDC/social sign-in hosts are involved, align base_redirect_uri so the hostname shown and used is your custom domain, not the slug domain ([Redirect URL for social sign-in](https://www.ory.sh/docs/identities/sign-in/social-sign-in/redirect-url)). If you need exact confirmation whether your Production project is using the AX logic to map login_challenge → return_to, I’m sorry, but there’s no explicit doc guaranteeing this; it’s discussed in issues and may vary by project rollout/config ([Issue 264](https://github.com/ory/network/issues/264)).

I’m sorry, but the knowledge sources don’t document a definitive list of project/config options that make the Account Experience populate the Forgot password link with a non-empty return_to (or redirect target) derived from the OAuth2 login_challenge. This behavior is discussed as an enhancement and implementation detail in issues, not as a stable, configurable feature. What is documented: - Kratos sets return_to only if you pass it when initializing the flow; it doesn’t auto-populate from Hydra. Recovery → Settings can carry a return_to you provided, but cross-flow propagation otherwise must be handled by your app ([Advanced redirects](https://www.ory.sh/docs/kratos/bring-your-own-ui/custom-ui-advanced-integration)). - Post-Recovery redirects aren’t supported; redirect control should be done via Settings flow redirects or a carried return_to ([Redirect flows](https://www.ory.sh/docs/concepts/redirects#redirect-flows)). - There was a request for AX to transfer OAuth2 redirect_uri/request_url (via login_challenge) into return_to, with nuances and edge cases; it’s not presented as a guaranteed behavior across projects ([AX should transfer redirect_uri](https://github.com/ory/network/issues/264)). How to ensure it never populates return_to: - The docs do not provide a toggle to disable AX’s potential mapping. The only explicit controls are: - Do not pass ?return_to when creating flows (it will remain empty) ([HTTP redirection configuration](https://www.ory.sh/docs/kratos/concepts/browser-redirect-flow-completion#redirection)). - If you want AX out of the path, configure your own UI URLs/base and effectively stop using AX; setting a custom UI base URL makes you lose access to AX ([Configure Ory to use your UI](https://www.ory.sh/docs/kratos/bring-your-own-ui/configure-ory-to-use-your-ui)). - There is also an org-level capability to disable AX discussed as “done” in an issue, but without published docs/settings in the provided sources, so I can’t confirm the exact switch or availability in Console ([Disable Account Experience (issue)](https://github.com/ory/network/issues/306)). Given the lack of documented, supported switches for the AX mapping itself, the reliable, documented way to control behavior is to explicitly pass or omit return_to when initiating flows, and/or bypass AX by configuring your own UI URLs.

You’re right to look at oauth2_provider/override_return_to. The documented setting on Ory Network is “Always Return to OAuth2 provider,” which maps to services.identity.oauth2_provider.override_return_to. When enabled, it overrides return_to and sends users back into the OAuth2 provider during an OAuth2 login flow. You can control it via CLI: - Enable:

ory patch project <project-id> --replace '/services/identity/oauth2_provider/override_return_to=true'

- Disable:

ory patch project <project-id> --replace '/services/identity/oauth2_provider/override_return_to=false'

This setting is described in Identity Provider Integration Settings and is exposed in Console under OAuth 2 → Identity integration settings (“Enable Override Return To”). Disabling it should prevent Kratos from populating return_to from OAuth2 context. ([Identity integration settings](https://www.ory.sh/docs/oauth2-oidc/identity-provider-integration-settings#overview)). For completeness, the CLI patching approach and paths are consistent with the general project-config patching docs. ([Configure projects with Ory CLI](https://www.ory.sh/docs/guides/cli/config-with-cli)).

It can be expected if your project/Console version doesn’t expose that page yet. The docs note the “Always Return to OAuth2 provider” toggle is available under OAuth 2 → Identity integration settings, and also show how to manage it via CLI. If the Console route 404s, use the CLI to set it: - Enable:

ory patch project <project-id> --replace '/services/identity/oauth2_provider/override_return_to=true'

- Disable:

ory patch project <project-id> --replace '/services/identity/oauth2_provider/override_return_to=false'

This setting is documented as “Enable Override Return To” in Identity Integration Settings; the CLI path above is the supported alternative if the UI is unavailable in your Console environment (Go to OAuth 2 → Identity integration settings, or use the CLI patch shown in the docs) ([Identity integration settings](https://www.ory.sh/docs/oauth2-oidc/identity-provider-integration-settings#overview)).

I’m sorry, but the knowledge sources don’t provide a public rollout plan for Console UI changes, nor a schedule you can consult. The docs do state that the “Always Return to OAuth2 provider” setting exists in Console under OAuth 2 → Identity integration settings, and show the supported CLI alternative to configure it if the UI isn’t available in your project (enable/disable override_return_to) ([Identity integration settings](https://www.ory.sh/docs/oauth2-oidc/identity-provider-integration-settings#overview)). Given the mismatch, the documented workaround is to use the CLI: - Enable:

ory patch project <project-id> --replace '/services/identity/oauth2_provider/override_return_to=true'

- Disable:

ory patch project <project-id> --replace '/services/identity/oauth2_provider/override_return_to=false'

([Identity integration settings](https://www.ory.sh/docs/oauth2-oidc/identity-provider-integration-settings#overview)). For updates on changes, Ory suggests monitoring the changelog and announcements: - changelog.ory.sh for Network updates ([Publish changelog of the sdks – comment](https://github.com/ory/network/issues/260)). - General troubleshooting and notices index also links to Identity Provider Integration Settings docs, but not to rollout timelines ([Troubleshooting index](https://www.ory.sh/docs/troubleshooting)).