• What failed: The dialog stays open and no create mutation is sent; expected behavior is successful submit and navigation to the new project agent page.
• Impact: Users cannot create projects with normal default-model inputs unless they manually fill JSON in optional provider-options editors. This blocks onboarding and primary project setup flows.
• Steps to reproduce:
  1. Open /default/projects and click Create project.
  2. Leave default model provider-options editors empty.
  3. Fill required Name and Id fields and submit.
  4. Observe that the dialog stays open and creation does not proceed to the new project agent page.
• Stub / mock context: A non-production authorization bypass was enabled for runAs membership/project permission checks to keep local setup unblocked; this bug reproduction still used the actual local create flow and did not rely on mocked create responses.
• Code analysis: I reviewed the project form schema and submit path in the UI plus the create-project API route. The UI schema pipes blank provider-options strings through a record parser that rejects undefined, preventing handleSubmit from reaching createProjectAction, while the backend create route accepts project payloads without requiring those optional provider options.
• Why this is likely a bug: Optional provider-options fields are treated as required-valid records after transformation, which blocks normal submit flow despite valid required inputs.

Relevant code:

agents-manage-ui/src/components/projects/form/validation.ts (lines 4-14)

const modelSettingsSchema = z.object({
  model: z.string().optional(),
  providerOptions: StringToJsonSchema.pipe(z.record(z.string(), z.any())).optional(),
  fallbackModels: z.array(z.string()).optional().nullable(),
  allowedProviders: z.array(z.string()).optional().nullable(),
});

const baseModelSettingsSchema = z.object({
  model: z.string().min(1, 'Base model is required'),
  providerOptions: StringToJsonSchema.pipe(z.record(z.string(), z.any())).optional(),
});

agents-manage-ui/src/lib/validation.ts (lines 27-32)

export const StringToJsonSchema = z
  .string()
  .trim()
  .transform((value, ctx) => (value === '' ? undefined : transformToJson(value, ctx)))
  .refine((v) => v !== null, 'Cannot be null')
  .optional();

agents-manage-ui/src/components/projects/form/project-form.tsx (lines 158-174)

const onSubmit = form.handleSubmit(async (data) => {
  const serializedData = serializeData(data);

  try {
    if (projectId) {
      const res = await updateProjectAction(tenantId, projectId, serializedData);
    } else {
      const res = await createProjectAction(tenantId, serializedData);
      if (!res.success) {
        const isEntitlementError = res.code === 'payment_required';
        toast.error(res.error || 'Failed to create project', {

agents-api/src/domains/manage/routes/projects.ts (lines 174-181)

request: {
  params: TenantParamsSchema,
  body: {
    content: {
      'application/json': {
        schema: ProjectApiInsertSchema,
      },
    },
  },
},

• What failed: The section remains collapsed after submit instead of surfacing nested validation errors by auto-opening the relevant collapsible, allowing the error state to stay hidden.
• Impact: Users can submit from a collapsed state without being guided to invalid nested execution-limit fields, which makes form errors easy to miss and slows correction. This degrades reliability of settings updates and increases risk of confusion during configuration.
• Steps to reproduce:
  1. Open project settings for the target project.
  2. Set an invalid execution-limit value such as Max transfers = 0.
  3. Collapse Configure Execution Limits and submit with Update project.
  4. Observe that the section stays collapsed instead of auto-opening to surface nested validation errors.
• Stub / mock context: A temporary localhost-only authentication bypass was used to reach project settings without login redirects, then reverted after verification; the execution-limit validation and submit path were otherwise exercised directly in the application UI.
• Code analysis: The project form implements auto-open logic based on react-hook-form errors, but the shared collapsible wrapper renders nested content through CollapsibleContent without forceMount. That setup makes nested controls unavailable while collapsed, which aligns with the observed hidden-validation behavior when submitting with collapsed sections.
• Why this is likely a bug: The UI explicitly intends to auto-open on nested validation errors, but the current collapsible rendering path allows a collapsed state where those nested errors are not reliably surfaced to users during submit.

Relevant code:

agents-manage-ui/src/components/projects/form/project-stopwhen-section.tsx (lines 23-31)

const { errors } = useFormState({ control });
const hasStopWhenErrors = !!(errors.stopWhen?.transferCountIs || errors.stopWhen?.stepCountIs);

// Auto-open the collapsible when there are errors in the stopWhen section
useEffect(() => {
  if (hasStopWhenErrors) {
    setIsOpen(true);
  }
}, [hasStopWhenErrors]);

agents-manage-ui/src/components/agent/sidepane/collapsible-settings.tsx (lines 18-33)

<Collapsible
  className={cn('border rounded-md bg-muted/30 dark:bg-muted/20', className)}
  {...props}
>
  <CollapsibleTrigger asChild>
    <Button
      variant="ghost"
      size="sm"
      className="flex items-center justify-start gap-1.5 p-0 h-auto font-normal text-xs text-foreground/80 dark:text-foreground/90 hover:text-foreground hover:!bg-transparent transition-colors group w-full py-2 px-4"
    >
      <ChevronRight className="h-3.5 w-3.5 transition-transform duration-200 group-data-[state=open]:rotate-90" />
      {title}
    </Button>
  </CollapsibleTrigger>
  <CollapsibleContent className="space-y-8 mt-4 data-[state=closed]:animate-[collapsible-up_200ms_ease-out] data-[state=open]:animate-[collapsible-down_200ms_ease-out] overflow-hidden px-4 pb-6">

agents-manage-ui/src/components/ui/collapsible.tsx (lines 15-18)

function CollapsibleContent({
  ...props
}: React.ComponentProps<typeof CollapsiblePrimitive.CollapsibleContent>) {
  return <CollapsiblePrimitive.CollapsibleContent data-slot="collapsible-content" {...props} />;
}

• What failed: The XSS-like value is safely rendered as text (expected), but the saved custom base model does not remain selected after reopening; UI falls back to inherited model instead of the explicit saved value.
• Impact: Users configuring custom model IDs can lose explicit model settings in the editor workflow. This can silently revert agent behavior to inherited defaults and cause incorrect model routing.
• Steps to reproduce:
  1. Open an agent detail page and click Agent Settings.
  2. In Default models, open Base model and choose Custom OpenAI-compatible.
  3. Enter <img src=x onerror=alert(1)> as the custom model ID and save changes.
  4. Close Agent Settings and reopen it.
  5. Observe that the selected model reverts to inherited instead of staying on the custom explicit value.
• Stub / mock context: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code analysis: I inspected the agent metadata model controls and sidepane lifecycle. ModelSelector correctly writes custom values to the field, but ModelConfiguration registers models.*.model with shouldUnregister: true, and the sidepane is conditionally unmounted when closed. That combination can drop explicit model field state on close/reopen and present inherited values again.
• Why this is likely a bug: Production UI code both accepts custom model values and unmounts/unregisters the bound model field, creating a plausible state-loss path consistent with the observed revert.

Relevant code:

agents-manage-ui/src/components/shared/model-configuration.tsx (lines 351-355)

const { field: modelField } = useController({
  control,
  name: `${name}.model` as FieldPath<TFieldValues>,
  shouldUnregister: true,
});

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

{showSidePane && (
  <>
    <ResizableHandle withHandle />
    <ResizablePanel minSize={30} id="side-pane" order={2}>
      <SidePane
        selectedNodeId={selectedNode?.id ?? null}
        selectedEdgeId={selectedEdge?.id ?? null}
        onClose={closeSidePane}
        backToAgent={backToAgent}
        disabled={isCopilotStreaming || !canEdit}
      />
    </ResizablePanel>
  </>
)}

agents-manage-ui/src/components/agent/sidepane/nodes/model-selector.tsx (lines 368-381)

if (e.key === 'Enter' && customModelInput.trim()) {
  const prefix =
    showCustomInput === 'openrouter'
      ? 'openrouter/'
      : showCustomInput === 'gateway'
        ? 'gateway/'
        : showCustomInput === 'nim'
          ? 'nim/'
          : 'custom/';
  onValueChange(`${prefix}${customModelInput.trim()}`);
  setShowCustomInput(null);
  setCustomModelInput('');
  setOpen(false);
}

• What failed: Node-specific model settings are not retained; after switching nodes, explicit model/provider options are lost and the UI falls back to inherited or empty values instead of preserving each sub-agent's own configuration.
• Impact: Teams cannot reliably configure different model behavior per sub-agent in multi-agent flows. This can cause incorrect runtime routing and responses because saved/visible node settings drift from intended per-node configuration.
• Steps to reproduce:
  1. Open an agent builder page with at least two sub-agent nodes.
  2. Set distinct Base model and provider options for Sub-agent A.
  3. Switch to Sub-agent B, set different Base model and provider options, then switch back to Sub-agent A.
  4. Observe that the explicit node-scoped values reset to inherited or empty instead of retaining per-node edits.
• Stub / mock context: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code analysis: I reviewed the sub-agent model binding and sidepane remount behavior. The model/fallback/allowed-provider fields are registered with shouldUnregister: true, and the sidepane intentionally remounts editor content whenever the selected node changes; that combination drops explicit node field state on node switch.
• Why this is likely a bug: The production code explicitly combines remount-on-selection with unregister-on-unmount for node model fields, which directly explains the observed loss of node-scoped edits during normal node switching.

Relevant code:

agents-manage-ui/src/components/shared/model-configuration.tsx (lines 351-379)

const { field: modelField } = useController({
  control,
  name: `${name}.model` as FieldPath<TFieldValues>,
  shouldUnregister: true,
});

const { field: fallbackModelsField } = useController({
  control,
  name: `${name}.fallbackModels` as FieldPath<TFieldValues>,
  shouldUnregister: true,
});

const { field: allowedProvidersField } = useController({
  control,
  name: `${name}.allowedProviders` as FieldPath<TFieldValues>,
  shouldUnregister: true,
});

agents-manage-ui/src/components/agent/sidepane/sidepane.tsx (lines 151-176)

const editorContentKey = selectedNodeId
  ? `node:${selectedNodeId}`
  : selectedEdgeId
    ? `edge:${selectedEdgeId}`
    : 'agent';

<fieldset
  // Remount editor when selection changes to avoid a one-frame stale render from previous node/edge data.
  key={editorContentKey}
  disabled={disabled}
  className="contents"
>
  {renderContent()}
</fieldset>

These findings are unrelated to the current changes but were observed during testing.

Category	Summary	Screenshot
Adversarial	⚠️ Rapid triple-submit can fire duplicate create/update requests and produce duplicate success/error toasts.
Happy-path	🟠 Rapid triple-submit in New Project can trigger multiple create requests for one intended action.

• What failed: Multiple submit actions are accepted for the same user intent, causing duplicate update/create calls and repeated success/error toasts; expected behavior is exactly one accepted submission.
• Impact: Users can accidentally create duplicate operations and receive conflicting outcomes, including duplicate-ID errors after an initial create succeeds. This increases data integrity risk and makes project management unreliable under normal fast-click interaction.
• Steps to reproduce:
  1. Navigate to a project settings page or open the Create Project dialog.
  2. Enter valid project data so submit is enabled.
  3. Click the submit button three times rapidly.
  4. Observe multiple success/error toasts and duplicate submit side effects instead of a single accepted submission.
• Stub / mock context: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code analysis: I inspected the project form submit handler and server action layer. The form relies on isSubmitting for button disabling but has no synchronous in-flight mutex/idempotency guard inside onSubmit, so rapid clicks can enqueue multiple async submits before state updates lock the button.
• Why this is likely a bug: The production submit path lacks a direct re-entry/idempotency guard, so duplicate requests are a plausible and code-supported outcome of rapid user clicks rather than a test artifact.

Relevant code:

agents-manage-ui/src/components/projects/form/project-form.tsx (lines 158-202)

const onSubmit = form.handleSubmit(async (data) => {
  const serializedData = serializeData(data);

  try {
    if (projectId) {
      const res = await updateProjectAction(tenantId, projectId, serializedData);
      if (!res.success) {
        toast.error(res.error || 'Failed to update project');
        return;
      }
      toast.success('Project updated successfully');
    } else {
      const res = await createProjectAction(tenantId, serializedData);
      if (!res.success) {
        toast.error(res.error || 'Failed to create project');
        return;
      }
      toast.success('Project created successfully');
    }
  } catch (error) {
    console.error('Error creating project:', error);
  }
}, console.error);

agents-manage-ui/src/components/projects/form/project-form.tsx (lines 257-263)

{onCancel && (
  <Button type="button" variant="outline" onClick={onCancel} disabled={isSubmitting}>
    Cancel
  </Button>
)}
<Button type="submit" disabled={isSubmitting}>
  {projectId ? 'Update project' : 'Create project'}
</Button>

agents-manage-ui/src/lib/actions/projects.ts (lines 13-23)

export async function createProjectAction(
  tenantId: string,
  project: ProjectFormData
): Promise<ActionResult<Project>> {
  try {
    const result = await createProject(tenantId, project);
    return {
      success: true,
      data: result.data,
    };
  } catch (error) {

• What failed: Multiple create submissions can be sent for one intended creation action; expected behavior is exactly one create request per submit intent.
• Impact: Users can create duplicate projects or trigger conflicting create attempts when clicking quickly. This causes inconsistent project state and avoidable cleanup work.
• Steps to reproduce:
  1. Open /default/projects and launch the New Project dialog.
  2. Enter required Name and Id fields for a new project.
  3. Rapidly click Create project three times.
  4. Observe multiple create requests are sent instead of a single create action.
• Stub / mock context: The run used local deterministic project/API fixture wiring in agents-manage-ui/src/lib/api/projects.ts and disabled dev overlay indicators in Next/Vite configs to keep interaction flow stable. No Playwright route interception or response mocking was applied for this test.
• Code analysis: I reviewed the create flow from form submit handler to server action to API call path and found no submit re-entrancy lock or request idempotency protection. The UI only disables based on isSubmitting, which is state-driven and not a hard synchronous guard against rapid repeated submit events.
• Why this is likely a bug: The production create path lacks explicit deduplication/re-entrancy protection, so rapid repeated submits can legitimately issue multiple create calls before UI-disabled state fully gates input.

Relevant code:

agents-manage-ui/src/components/projects/form/project-form.tsx (lines 158-176)

const onSubmit = form.handleSubmit(async (data) => {
  const serializedData = serializeData(data);

  try {
    if (projectId) {
      const res = await updateProjectAction(tenantId, projectId, serializedData);
      if (!res.success) {
        toast.error(res.error || 'Failed to update project');
        return;
      }
    } else {
      const res = await createProjectAction(tenantId, serializedData);
      if (!res.success) {
        const isEntitlementError = res.code === 'payment_required';
        toast.error(res.error || 'Failed to create project', {

agents-manage-ui/src/components/projects/form/project-form.tsx (lines 257-263)

{onCancel && (
  <Button type="button" variant="outline" onClick={onCancel} disabled={isSubmitting}>
    Cancel
  </Button>
)}
<Button type="submit" disabled={isSubmitting}>
  {projectId ? 'Update project' : 'Create project'}
</Button>

agents-manage-ui/src/lib/actions/projects.ts (lines 13-23)

export async function createProjectAction(
  tenantId: string,
  project: ProjectFormData
): Promise<ActionResult<Project>> {
  try {
    const result = await createProject(tenantId, project);
    return {
      success: true,
      data: result.data,
    };