@agent-native/core 0.157.20 → 0.157.21

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (30) hide show
  1. package/corpus/templates/analytics/.agents/skills/security/SKILL.md +29 -0
  2. package/corpus/templates/assets/.agents/skills/security/SKILL.md +29 -0
  3. package/corpus/templates/brain/.agents/skills/security/SKILL.md +29 -0
  4. package/corpus/templates/calendar/.agents/skills/security/SKILL.md +29 -0
  5. package/corpus/templates/chat/.agents/skills/security/SKILL.md +29 -0
  6. package/corpus/templates/clips/.agents/skills/security/SKILL.md +29 -0
  7. package/corpus/templates/content/.agents/skills/security/SKILL.md +29 -0
  8. package/corpus/templates/crm/.agents/skills/security/SKILL.md +29 -0
  9. package/corpus/templates/design/.agents/skills/security/SKILL.md +29 -0
  10. package/corpus/templates/dispatch/.agents/skills/security/SKILL.md +29 -0
  11. package/corpus/templates/factory/.agents/skills/security/SKILL.md +29 -0
  12. package/corpus/templates/forms/.agents/skills/security/SKILL.md +29 -0
  13. package/corpus/templates/macros/.agents/skills/security/SKILL.md +29 -0
  14. package/corpus/templates/mail/.agents/skills/security/SKILL.md +29 -0
  15. package/corpus/templates/plan/.agents/skills/security/SKILL.md +29 -0
  16. package/corpus/templates/slides/.agents/skills/security/SKILL.md +29 -0
  17. package/corpus/templates/tasks/.agents/skills/security/SKILL.md +29 -0
  18. package/dist/collab/struct-routes.d.ts +1 -1
  19. package/dist/mcp/screen-memory-stdio.d.ts +7 -7
  20. package/dist/notifications/routes.d.ts +3 -3
  21. package/dist/observability/routes.d.ts +1 -1
  22. package/dist/templates/chat/.agents/skills/security/SKILL.md +29 -0
  23. package/dist/templates/default/.agents/skills/security/SKILL.md +29 -0
  24. package/dist/templates/headless/.agents/skills/security/SKILL.md +29 -0
  25. package/dist/templates/workspace-core/.agents/skills/security/SKILL.md +29 -0
  26. package/package.json +1 -1
  27. package/src/templates/chat/.agents/skills/security/SKILL.md +29 -0
  28. package/src/templates/default/.agents/skills/security/SKILL.md +29 -0
  29. package/src/templates/headless/.agents/skills/security/SKILL.md +29 -0
  30. package/src/templates/workspace-core/.agents/skills/security/SKILL.md +29 -0
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -13,8 +13,8 @@
13
13
  * Body: { json: any, fieldName?: string, type?: "map"|"array", requestSource?: string }
14
14
  */
15
15
  export declare const postCollabJson: import("h3").EventHandlerWithFetch<import("h3").EventHandlerRequest, Promise<{
16
- error: string;
17
16
  ok?: undefined;
17
+ error: string;
18
18
  } | {
19
19
  error?: undefined;
20
20
  ok: boolean;
@@ -137,13 +137,13 @@ export declare function screenMemoryMcpToolDefinitions(): ({
137
137
  inputSchema: {
138
138
  type: string;
139
139
  properties: {
140
- count?: undefined;
141
140
  query?: undefined;
142
141
  minutes?: undefined;
143
142
  limit?: undefined;
144
143
  clientHint?: undefined;
145
144
  timestamp?: undefined;
146
145
  chapterId?: undefined;
146
+ count?: undefined;
147
147
  startAt?: undefined;
148
148
  endAt?: undefined;
149
149
  reason?: undefined;
@@ -159,7 +159,6 @@ export declare function screenMemoryMcpToolDefinitions(): ({
159
159
  inputSchema: {
160
160
  type: string;
161
161
  properties: {
162
- count?: undefined;
163
162
  query: {
164
163
  type: string;
165
164
  description: string;
@@ -175,6 +174,7 @@ export declare function screenMemoryMcpToolDefinitions(): ({
175
174
  clientHint?: undefined;
176
175
  timestamp?: undefined;
177
176
  chapterId?: undefined;
177
+ count?: undefined;
178
178
  startAt?: undefined;
179
179
  endAt?: undefined;
180
180
  reason?: undefined;
@@ -190,7 +190,6 @@ export declare function screenMemoryMcpToolDefinitions(): ({
190
190
  inputSchema: {
191
191
  type: string;
192
192
  properties: {
193
- count?: undefined;
194
193
  minutes: {
195
194
  type: string;
196
195
  description: string;
@@ -200,6 +199,7 @@ export declare function screenMemoryMcpToolDefinitions(): ({
200
199
  clientHint?: undefined;
201
200
  timestamp?: undefined;
202
201
  chapterId?: undefined;
202
+ count?: undefined;
203
203
  startAt?: undefined;
204
204
  endAt?: undefined;
205
205
  reason?: undefined;
@@ -216,7 +216,6 @@ export declare function screenMemoryMcpToolDefinitions(): ({
216
216
  type: string;
217
217
  required: string[];
218
218
  properties: {
219
- count?: undefined;
220
219
  query: {
221
220
  type: string;
222
221
  description: string;
@@ -235,6 +234,7 @@ export declare function screenMemoryMcpToolDefinitions(): ({
235
234
  };
236
235
  timestamp?: undefined;
237
236
  chapterId?: undefined;
237
+ count?: undefined;
238
238
  startAt?: undefined;
239
239
  endAt?: undefined;
240
240
  reason?: undefined;
@@ -250,7 +250,6 @@ export declare function screenMemoryMcpToolDefinitions(): ({
250
250
  type: string;
251
251
  required: string[];
252
252
  properties: {
253
- count?: undefined;
254
253
  query?: undefined;
255
254
  minutes?: undefined;
256
255
  limit?: undefined;
@@ -264,6 +263,7 @@ export declare function screenMemoryMcpToolDefinitions(): ({
264
263
  description: string;
265
264
  };
266
265
  chapterId?: undefined;
266
+ count?: undefined;
267
267
  startAt?: undefined;
268
268
  endAt?: undefined;
269
269
  includeMicrophone?: undefined;
@@ -314,13 +314,13 @@ export declare function screenMemoryMcpToolDefinitions(): ({
314
314
  type: string;
315
315
  required: string[];
316
316
  properties: {
317
- count?: undefined;
318
317
  query?: undefined;
319
318
  minutes?: undefined;
320
319
  limit?: undefined;
321
320
  clientHint?: undefined;
322
321
  timestamp?: undefined;
323
322
  chapterId?: undefined;
323
+ count?: undefined;
324
324
  startAt: {
325
325
  type: string;
326
326
  description: string;
@@ -349,13 +349,13 @@ export declare function screenMemoryMcpToolDefinitions(): ({
349
349
  type: string;
350
350
  required: string[];
351
351
  properties: {
352
- count?: undefined;
353
352
  query?: undefined;
354
353
  minutes?: undefined;
355
354
  limit?: undefined;
356
355
  clientHint?: undefined;
357
356
  timestamp?: undefined;
358
357
  chapterId?: undefined;
358
+ count?: undefined;
359
359
  startAt?: undefined;
360
360
  endAt?: undefined;
361
361
  reason?: undefined;
@@ -16,18 +16,18 @@ export declare function createNotificationsHandler(): import("h3").EventHandlerW
16
16
  error?: undefined;
17
17
  ok?: undefined;
18
18
  } | {
19
- count?: undefined;
20
19
  updated: number;
21
20
  error?: undefined;
22
21
  ok?: undefined;
23
- } | {
24
22
  count?: undefined;
23
+ } | {
25
24
  updated?: undefined;
26
25
  error: string;
27
26
  ok?: undefined;
28
- } | {
29
27
  count?: undefined;
28
+ } | {
30
29
  updated?: undefined;
31
30
  error?: undefined;
32
31
  ok: boolean;
32
+ count?: undefined;
33
33
  }>>;
@@ -62,6 +62,6 @@ export declare function createObservabilityHandler(): import("h3").EventHandlerW
62
62
  summary?: undefined;
63
63
  spans?: undefined;
64
64
  id?: undefined;
65
- ok: boolean;
66
65
  error?: undefined;
66
+ ok: boolean;
67
67
  }>>;
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@agent-native/core",
3
- "version": "0.157.20",
3
+ "version": "0.157.21",
4
4
  "description": "Framework for agent-native application development — where AI agents and UI share SQL state, actions, and context",
5
5
  "homepage": "https://github.com/BuilderIO/agent-native#readme",
6
6
  "bugs": {
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one
@@ -149,6 +149,35 @@ export default defineEventHandler(async (event) => {
149
149
 
150
150
  - Never create unprotected routes that modify data.
151
151
 
152
+ ## Same-Origin Workspace Apps
153
+
154
+ Path-mounted workspace apps share the Dispatch gateway origin. Because the
155
+ framework's session cookie is scoped to `/`, a mounted pane receives the
156
+ ambient Dispatch session and can act as the signed-in user through same-origin
157
+ requests. This is an intentional trusted-code model, not an isolation
158
+ boundary; removing a mounted app from SSO fanout does not revoke that ambient
159
+ access.
160
+
161
+ Only trusted, workspace-owner-authored code belongs on that origin. Treat each
162
+ of these as a trust-boundary change that requires an explicit origin, sandbox,
163
+ or capability design before shipping:
164
+
165
+ - non-owners can create or edit mounted app code;
166
+ - mounted apps render or execute untrusted external content or remote code;
167
+ - apps are publicly shareable, anonymously reachable, or installable by users
168
+ outside the owning workspace;
169
+ - app source, dependencies, or deployment artifacts can be replaced by a
170
+ third party without the workspace owner's authorization;
171
+ - a mounted app can be registered across workspaces or can change its mount
172
+ path/origin without an ownership check; or
173
+ - cookie scope, proxying, iframe policy, or navigation changes make this
174
+ ambient-session behavior broader than the owning workspace.
175
+
176
+ Do not describe canonical-only SSO eligibility as origin isolation. Canonical
177
+ apps and explicitly registered custom origins remain eligible; path-mounted
178
+ apps are deliberately excluded as SSO targets while retaining their existing
179
+ same-origin session behavior.
180
+
152
181
  **Exception — the SSR HTML/`.data` catch-all is deliberately session-blind.**
153
182
  The rule above is for routes that read or mutate user data. The SSR page
154
183
  render and React Router `.data` route are different: they serve one