Focused view blocked in demo: DocuSign redirects to demo.docusign.net:7802 (bailout=focused_view_v2)

Since early October 2026, embedded signing with focused view fails on our demo account. The signer sees "This content is blocked. Contact the site owner to fix the issue." inside the focused-view iframe. The browser console shows:

Framing 'https://demo.docusign.net:7802/' violates the following Content Security Policy directive: "frame-src 'self' https://docucdn-a.akamaihd.net/ https://apps-d.docusign.com https://demo.docusign.net ..."

Nothing changed on our side: the same code that worked in September fails now, and displayFormat: "default" still works with the same envelopes, so the integration key, recipient view request and frame settings are valid.

What we found

We reproduced it with plain HTTP requests, outside our app and outside any browser. docusign.js (0.0.61, widget @embedded/signing-ui 1.0.221) appends platform=focused to the recipient view URL. With that parameter, the redirect chain ends like this:

1. demo.docusign.net/Signing/MTRedeem/v1/... → account-d.docusign.com/managed_token/v1/redeem → demo.docusign.net/Signing/StartInSession.aspx → demo.docusign.net/Signing/?insession=1&ti=...
2. That last request returns 302 to
   https://apps-d.docusign.com/embedded-signing?url=https%3A%2F%2Fdemo.docusign.net%3A7802%2FSigning%2F%3Finsession%3D1%26ti%3D...&display_format=focused&source=api&bailout=focused_view_v2
3. apps-d.docusign.com/embedded-signing then tries to frame https://demo.docusign.net:7802/, which its own CSP blocks.

Port 7802 matches the pv cookie the demo nodes set (pv=<node>_7802), so the fallback URL looks like it is built from the node's internal listener instead of the public host.

Control: the same recipient view opened without platform=focused redirects to https://apps-d.docusign.com/authenticate?code=...&state=... and signing works normally.

Reproducibility: 4 of 4 fresh focused-view sessions across six different demo nodes returned the malformed redirect; the control session worked. It happens for template-based envelopes and for a plain envelope with one inline PDF and one signHere tab, so it is not envelope-specific.

Request details

• authenticationMethod: "Email", clientUserId set
• frameAncestors: ["https://<our app origin>", "https://apps-d.docusign.com", "https://demo.docusign.net"] (removing https://demo.docusign.net makes no difference)
• messageOrigins: ["https://apps-d.docusign.com"]
• Chrome 152 on Windows; also reproduced with curl
• Our recipient view URLs are still issued on demo.docusign.net, not apps-d.docusign.com, despite the July–August 2026 demo domain update; we don't know whether that is related

Questions

1. Is this a known issue with the focused_view_v2 fallback in demo? Can the redirect be corrected to use the public host without the internal port?
2. Is it tied to the embedded signing URL domain migration, and should our account have been migrated?
3. Is there anything in account configuration or in the recipient view request that triggers the bailout?

Happy to share trace tokens, account ID and HAR files privately with DocuSign staff.