• Where: Agent builder graph keyboard interaction layer (node selection/delete + undo shortcut handling).

• Steps to reproduce: Select a deletable node on canvas -> press Delete -> press Ctrl/Cmd+Z.

• What failed: Node deletion occurs, but undo does not reliably restore the deleted node state.

• Code analysis: The keyboard handler exits unless the key event target has react-flow__node, which can stop undo handling after focus changes during deletion. This creates a plausible path where deletion happens but follow-up undo is not processed.

• Relevant code:

  agents-manage-ui/src/features/agent/ui/use-agent-shortcuts.ts (lines 46-70)

  function onKeyDown(e: KeyboardEvent) {
    if (!(e.target as HTMLElement)?.classList.contains('react-flow__node')) return;
    const meta = e.metaKey || e.ctrlKey;
    if (meta && e.key.toLowerCase() === 'z') {
      e.preventDefault();
      if (e.shiftKey) {
        redo();
      } else {
        undo();
      }
      return;
    }
  }

  agents-manage-ui/src/features/agent/ui/use-agent-shortcuts.ts (lines 13-43)

  function deleteSelected() {
    agentStore.setState((state) => {
      const nodesToDelete = new Set(
        state.nodes
          .filter((n) => n.selected && (n.deletable ?? true) && n.id !== defaultSubAgentIdRef.current)
          .map((n) => n.id)
      );
      const edgesRemaining = state.edges.filter(
        (e) => !e.selected && !nodesToDelete.has(e.source) && !nodesToDelete.has(e.target)
      );
      const nodesRemaining = state.nodes.filter((n) => !nodesToDelete.has(n.id));
      return { history: [...state.history, { nodes: state.nodes, edges: state.edges }], nodes: nodesRemaining, edges: edgesRemaining, dirty: true };
    });
  }

• Why this is likely a bug: Undo logic is present, but the strict event-target gate can block shortcut processing in normal post-delete focus states, producing the observed restore failure.

• Introduced by this PR: Yes - this PR modified the relevant shortcut handling code.

• Timestamp: 3:18

• Where: MCP node editor relation hydration and form-key lifecycle after save.

• Steps to reproduce: Edit MCP headers -> save -> relationshipId is hydrated for the node -> reload/reopen editor.

• What failed: Header edits do not persist exactly and can revert to fallback/default content.

• Code analysis: MCP relation form state is keyed by relationshipId ?? node.id, but initialization effect only depends on selectedNode.id. When relationshipId changes after save, the effect does not re-run for the new key, allowing stale/fallback relation data to be shown and serialized.

• Relevant code:

  agents-manage-ui/src/components/agent/sidepane/nodes/mcp-node-editor.tsx (lines 48-53)

  const relationKey = selectedNode.data.relationshipId ?? selectedNode.id;
  const mcpRelation = useWatch({
    control: form.control,
    name: `mcpRelations.${relationKey}`,
  });

  agents-manage-ui/src/components/agent/sidepane/nodes/mcp-node-editor.tsx (lines 89-109)

  useEffect(() => {
    const existingRelation = form.getValues(`mcpRelations.${relationKey}`);
    if (existingRelation) {
      return;
    }
    form.setValue(`mcpRelations.${relationKey}`, {
      toolId: selectedNode.data.toolId,
      relationshipId: selectedNode.data.relationshipId ?? undefined,
    }, { shouldDirty: false });
  }, [selectedNode.id]);

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

  // Update MCP nodes with new relationshipIds from backend response
  setNodes((currentNodes) =>
    currentNodes.map((node) => {
      if (node.type === NodeType.MCP) {
        const mcpNode = node as Node & { data: MCPNodeData };
        if (mcpNode.data.subAgentId && mcpNode.data.toolId) {
          if (mcpNode.data.relationshipId) return node;
          // ...find matching relationship...
          return { ...node, data: { ...node.data, relationshipId: matchingRelationship.agentToolRelationId } };
        }
      }
      return node;
    })
  );

• Why this is likely a bug: The relation key can change from node-id to relationship-id, but initialization is not keyed to that change, which is a concrete persistence/hydration defect path in production code.

• Introduced by this PR: Yes - this PR modified MCP relation serialization/editor and hydration paths.

• Timestamp: 13:24

• Where: External agent URL validation in shared schema used by manage UI and API.

• Steps to reproduce: Enter external agent baseUrl using javascript: scheme and submit/save.

• What failed: Unsafe scheme input is accepted instead of being rejected to http/https-only.

• Code analysis: The schema validates baseUrl with z.url(), which checks URL shape but does not enforce safe protocol allowlisting. The form schema directly uses this baseUrl field from shared agent schema.

• Relevant code:

  packages/agents-core/src/validation/schemas.ts (lines 1785-1790)

  export const ExternalAgentInsertSchema = createInsertSchema(externalAgents).extend({
    id: ResourceIdSchema,
    name: NameSchema,
    description: DescriptionSchema,
    baseUrl: z.url(),
    credentialReferenceId: z.string().trim().nonempty().max(256).nullish(),
  });

  agents-manage-ui/src/components/agent/form/validation.ts (lines 16-23)

  const ExternalAgentSchema = AgentWithinContextOfProjectSchema.shape.externalAgents
    .unwrap()
    .valueType.pick({
      name: true,
      id: true,
      description: true,
      baseUrl: true,
    });

• Why this is likely a bug: Production validation currently accepts URL schemes beyond safe web transports, allowing clearly unsafe javascript: values through normal save paths.

• Introduced by this PR: Unknown - unable to determine.

• Timestamp: 1:11:39

Screen Recording