Auto-discovered harness Profiles omit the catalogue allow-all launch mode

[mydmdm]

Summary

Profiles automatically provisioned from agentlet harness discovery do not enable the harness catalogue's supported allow-all / auto-approval mode by default.

For example, agentlet correctly reports the GitHub Copilot recipe as:

binary: copilot
acpArgs: [--acp]
autoApprove: { args: [--allow-all], position: after-acp }

but Huabu persists the automatic Profile command as:

copilot --acp

instead of:

copilot --acp --allow-all

The resulting automatically discovered Profile can unexpectedly stop for tool approvals and does not provide the intended ready-to-use autonomous Agent behavior.

Confirmed cause

harness-profile-discovery.ts constructs an automatic Profile with:

command: [harness.binary, ...harness.acpArgs].join(' ')

It ignores harness.autoApprove, even though that field is part of the versioned discovery contract and the trusted daemon-local catalogue. The existing discovery test explicitly expects copilot --acp, preserving the incorrect behavior.

The manual Profile form already has the canonical ordering logic:

• before-acp: binary + autoApprove.args + acpArgs
• after-acp: binary + acpArgs + autoApprove.args

Expected behavior

• Automatically provisioned Profiles default to the catalogue's official auto-approval recipe when autoApprove is non-null.
• Copilot defaults to copilot --acp --allow-all.
• Gemini and Qwen use their catalogue-defined approval modes.
• Kimi and Cursor preserve the required before-acp ordering.
• Harnesses whose catalogue entry has autoApprove: null remain unchanged; Huabu must not invent undocumented permission flags.
• Manually created Profiles retain their current explicit checkbox behavior and are not silently changed.
• Settings accurately display the effective launch mode for automatic Profiles.

Existing automatic Profiles

Define a safe migration/reconciliation policy for Profiles already created without the catalogue recipe:

• Preserve Profile ID, alias, workspace, placement, metadata, and unrelated customization.
• Upgrade only Profiles carrying valid customData.discoveredAgent provenance whose launch command still matches the exact previously generated default.
• Do not rewrite a command that was customized or whose provenance/recipe is ambiguous.
• Make the migration idempotent and version-aware so reconnects do not repeatedly mutate Profiles.
• Do not delete/recreate a Profile merely to change its generated command, because existing Agent bindings and workload snapshots reference stable Profile IDs.

If the current Profile registry intentionally makes launch identity immutable, add an explicit registry-owned migration mechanism rather than bypassing that boundary.

Acceptance criteria

• One shared helper composes catalogue launch commands with correct before-acp / after-acp ordering.
• Automatic discovery uses that helper and includes autoApprove for every harness with an official recipe.
• Manual Profile creation and automatic provisioning cannot drift in launch-command composition.
• Existing unmodified automatic Profiles are migrated safely without changing their IDs.
• Customized/manual Profiles and harnesses without recipes are preserved unchanged.
• Tests cover Copilot, Gemini/Qwen, Kimi/Cursor, a null-recipe harness, idempotent reconnect, and migration/customization protection.
• docs/architecture/agent-profiles.md documents the automatic Profile permission-mode default and migration behavior.

Relevant code

• external/agentlet/packages/local/src/harnesses/catalogue.ts
• external/agentlet/packages/protocol/src/messages.ts
• apps/server/src/modules/agent/acp/harness-profile-discovery.ts
• apps/server/src/modules/agent/acp/harness-profile-discovery.test.ts
• apps/web/src/components/Settings/agent-profiles/CommandProfileForm.tsx
• docs/architecture/agent-profiles.md

Related

• Automatically provision external Agent Profiles from agentlet discovery #174

[mydmdm]

Additional confirmed impact: the generated launch mode is not user-correctable in the current UI. Existing command Profiles have immutable launch identity; when editing, the launch command is displayed read-only and the catalogue-backed allow-all checkbox is disabled. Therefore an automatically discovered Copilot Profile created as copilot --acp cannot be changed to copilot --acp --allow-all in place. Deleting it permits rediscovery of the same incorrect default, while creating a separate manual Profile loses the intended zero-configuration automatic path. The fix must cover both correct defaults and an ID-preserving migration/update seam for existing unmodified automatic Profiles; merely changing future creation is insufficient.