• What failed: The API rejects explicit empty allowlists with a validation error (min(1)), but expected behavior is to allow creating the app and then deny all origins until domains are configured.
• Impact: Teams cannot configure or test an explicit fail-closed (deny-all) web client app state through supported create/update APIs. This blocks the intended safe baseline flow and makes config behavior inconsistent between write-time validation and runtime auth.
• Introduced by this PR: No – pre-existing bug (code not changed in this PR)
• Steps to reproduce:
  1. Send a POST request to /manage/tenants/default/projects/andrew/apps for a web_client app with config.webClient.allowedDomains set to an empty array.
  2. Observe that the request is rejected with a validation error requiring at least one domain.
  3. Compare runtime origin validation behavior, which denies requests when allowedDomains is empty (fail-closed), showing write/runtime inconsistency.
• Stub / mock context: App management requests used a local bypass bearer token instead of interactive admin login, and local project/agent seed records were created before execution so the target app path existed. No route interception or response stubbing was applied to the origin-validation code path.
• Code analysis: I traced app creation/update request validation and runtime auth enforcement; create/update uses AppApiInsertSchema/AppApiUpdateSchema, which currently enforce allowedDomains length >= 1, while runtime auth explicitly handles empty arrays as denied origins.
• Why this is likely a bug: The write path forbids an empty allowlist while the runtime path is explicitly coded to support empty allowlists as a deny-all state, indicating inconsistent production logic rather than test setup interference.

Relevant code:

packages/agents-core/src/validation/schemas.ts (lines 1735-1741)

export const WebClientConfigSchema = z
  .object({
    type: z.literal('web_client'),
    webClient: z.object({
      allowedDomains: z.array(AllowedDomainSchema).min(1),
      auth: WebClientAuthConfigSchema.optional(),
    }),
  })
  .openapi('WebClientConfig');

agents-api/src/domains/manage/routes/apps.ts (lines 134-140)

request: {
      params: TenantProjectParamsSchema,
      body: {
        content: {
          'application/json': {
            schema: AppApiInsertSchema,
          },
        },
      },
    },

packages/agents-core/src/utils/domain-validation.ts (lines 1-7)

export function validateOrigin(
  origin: string | null | undefined,
  allowedDomains: string[]
): boolean {
  if (!origin || allowedDomains.length === 0) {
    return false;
  }
}

• What failed: The chat composer shrinks to a near-unusable width and interaction is obstructed by layout overlap, instead of keeping input and send controls fully usable on mobile.
• Impact: Mobile users can be blocked from reliably composing or sending messages in Playground. This prevents core validation flows on small devices and undermines agent testing usability.
• Introduced by this PR: No – pre-existing bug (code not changed in this PR)
• Steps to reproduce:
  1. Open /default/projects/andrew/agents/friendly-agent in the Manage UI.
  2. Switch to a 390x844 mobile viewport.
  3. Open Playground with the Try it action.
  4. Type and send a message while the mobile sidebar state is active.
  5. Observe the composer width and whether the send control remains usable.
• Stub / mock context: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code analysis: The agent page always renders a horizontal ResizablePanelGroup with persisted desktop-style layout state and enforces a minimum playground split, but there is no mobile-specific pane strategy. In parallel, the mobile sidebar is rendered as an 18rem sheet overlay, which can consume most of a 390px viewport and overlap the already constrained workspace.
• Why this is likely a bug: Production layout code combines desktop horizontal pane constraints with a large mobile overlay sidebar and no mobile override, which directly creates the observed input obstruction on narrow screens.

Relevant code:

agents-manage-ui/src/app/[tenantId]/projects/[projectId]/agents/[agentId]/page.client.tsx (lines 575-580)

<ResizablePanelGroup
  id="agent-panel-group"
  direction="horizontal"
  autoSaveId="agent-resizable-layout-state"
  className="relative bg-muted/20 dark:bg-background flex overflow-hidden no-parent-container"
>

agents-manage-ui/src/app/[tenantId]/projects/[projectId]/agents/[agentId]/page.client.tsx (lines 723-729)

<ResizablePanel
  minSize={25}
  id="playground-pane"
  order={3}
  className={showTraces ? 'w-full flex-none!' : ''}
>

agents-manage-ui/src/components/ui/sidebar.tsx (lines 174-183)

if (isMobile) {
  return (
    <Sheet open={openMobile} onOpenChange={setOpenMobile} {...props}>
      <SheetContent
        data-sidebar="sidebar"
        className="bg-sidebar text-sidebar-foreground w-(--sidebar-width) p-0 [&>button]:hidden"
        style={{ ['--sidebar-width' as string]: SIDEBAR_WIDTH_MOBILE }}