feat(config): add triage-agent to default allowed_remote_resources

[ggallen]

Summary

• Add https://raw.githubusercontent.com/fullsend-ai/triage-agent/ to the default AllowedRemoteResources in NewOrgConfig() so harness wrappers can reference the external triage agent via base: composition (ADR-0045)
• Inert for existing installations that don't reference triage-agent URLs yet; new installs and fullsend admin upgrade will have the entry ready

Part of the triage agent migration to fullsend-ai/triage-agent.

Test plan

• TestNewOrgConfig updated to assert the new entry
• All internal/config/ tests pass

🤖 Generated with Claude Code

[qodo-code-review]

PR Summary by Qodo

Add triage-agent to default AllowedRemoteResources allowlist
✨ Enhancement ⚙️ Configuration changes 🧪 Tests 🕐 10-20 Minutes

Description

• Allow harness wrappers to reference triage-agent via base: composition (ADR-0045).
• Add triage-agent GitHub raw URL to the default org allowlist in NewOrgConfig().
• Update TestNewOrgConfig to assert the expanded default allowlist.

Diagram

graph TD
  E["Harness wrappers (base:)"] --> B["AllowedRemoteResources"] --> G["GitHub raw content"]
  B --> C["fullsend repo URL"] --> G
  B --> D["triage-agent repo URL"] --> G

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Pin allowlist to a versioned path (tag/SHA)

• ➕ Reduces risk of upstream content changes affecting new installs unexpectedly
• ➕ Makes upgrades more deterministic and auditable
• ➖ Harder to maintain (requires updating allowlist when versions change)
• ➖ May not fit the desired workflow for base: composition if it expects a moving branch

2. Make the triage-agent allowlist entry opt-in via explicit config migration

• ➕ Avoids changing defaults for new installs unless they enable triage-agent usage
• ➕ Keeps default allowlist minimal
• ➖ Creates extra operational steps and potential support friction
• ➖ Undercuts the goal of having upgrades/new installs “ready” for triage-agent composition

3. Host triage-agent resources under the existing fullsend raw URL namespace

• ➕ Avoids expanding the allowlist to additional repos/domains
• ➕ Centralizes remote base content under one repository
• ➖ Not aligned with the ongoing migration to fullsend-ai/triage-agent
• ➖ Requires additional publishing/sync process between repos

Recommendation: The PR’s approach is appropriate for ADR-0045 Phase 2: adding a second default allowlist entry is the lowest-friction way to enable base: composition against the new triage-agent repo while staying inert for existing installs. If supply-chain rigidity becomes a concern, consider pairing this with version-pinning in the harness wrapper references (or a future allowlist entry that targets a tag/SHA-specific path).

Files changed (2) +5 / -1

Tests (1) +4 / -1

config_test.goUpdate NewOrgConfig test to assert both default allowlist entries +4/-1

Update NewOrgConfig test to assert both default allowlist entries

• Updates 'TestNewOrgConfig' to expect the default allowlist to contain both the existing fullsend URL and the new triage-agent URL. This guards the intended default behavior for new org configs and upgrades.

internal/config/config_test.go

Other (1) +1 / -0

config.goExpand default AllowedRemoteResources to include triage-agent +1/-0

Expand default AllowedRemoteResources to include triage-agent

• Adds 'https://raw.githubusercontent.com/fullsend-ai/triage-agent/' to the default 'AllowedRemoteResources' returned by 'NewOrgConfig()'. This enables harness wrapper 'base:' composition to reference the external triage-agent repository by default.

internal/config/config.go

[github-actions]

Site preview

Preview: https://bfffdcfe-site.fullsend-ai.workers.dev

Commit: aa1798ddd3a94f262402285e35c4ef96b3d30a6c

[fullsend-ai-review]

🤖 Finished Review · ✅ Success · Started 3:11 PM UTC · Completed 3:20 PM UTC
Commit: aa1798d · View workflow run →

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 51 rules

✅ Skills: writing-user-docs, writing-adrs

1. Expanded default trust boundary 🐞 Bug ⛨ Security

Description

NewOrgConfig() now unconditionally adds
https://raw.githubusercontent.com/fullsend-ai/triage-agent/ to the org-level
AllowedRemoteResources, expanding what URL base: references are permitted by default. Since URL
base composition is authorized solely by the org allowlist, any harness can now reference a
triage-agent raw URL base without additional org configuration, which may be an unintended policy
expansion for orgs that didn’t enable/use triage.

Code

internal/config/config.go[R131-134]

		AllowedRemoteResources: []string{
			"https://raw.githubusercontent.com/fullsend-ai/fullsend/",
+			"https://raw.githubusercontent.com/fullsend-ai/triage-agent/",
		},

Relevance

⭐ Low

Team intentionally expanded defaults for base composition; similar least-privilege downscoping
requests were rejected (PRs 2300, 2407).

PR-#2300
PR-#2407

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The new default prefix is added in NewOrgConfig() regardless of the provided roles. URL base
composition explicitly treats the org allowlist as the authority for URL bases, so adding a prefix
here directly expands which URL bases can be used by default. The ADR describes
allowed_remote_resources as a user-controlled trust boundary with defaults that should be
“sensible,” so expanding it should be deliberate/least-privilege.

internal/config/config.go[110-147]
internal/harness/compose.go[107-117]
docs/ADRs/0038-universal-harness-access.md[234-267]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`internal/config.NewOrgConfig()` always adds `https://raw.githubusercontent.com/fullsend-ai/triage-agent/` to `AllowedRemoteResources`, which expands the default allowlist (trust boundary) for URL `base:` composition.

### Issue Context
- URL base composition is authorized against the **org-level** allowlist (`ComposeOpts.OrgAllowlist`). If the org allowlist contains a prefix, URL bases under that prefix are permitted.
- `NewOrgConfig()` receives the requested `roles` list, but the new allowlist entry is added regardless of whether triage is enabled/used.

### Suggested fix
Implement least-privilege defaults by only including the triage-agent prefix when it’s actually needed. Options:
1. **Conditional default**: only append the triage-agent prefix when `roles` includes `"triage"` (or when some explicit “triage-agent wrappers enabled” flag is set).
2. **More specific prefix**: if feasible, restrict to the smallest stable path prefix you expect to fetch from (instead of the repo root).
3. Update/extend `TestNewOrgConfig` to cover both cases (with triage role vs without triage role) so default behavior is locked in.

### Fix Focus Areas
- internal/config/config.go[110-147]
- internal/config/config_test.go[46-67]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[fullsend-ai-review]

Looks good to me

---

Labels: PR modifies default org config constructor (NewOrgConfig) to support triage-agent migration

[fullsend-ai-retro]

🤖 Finished Retro · ✅ Success · Started 12:04 PM UTC · Completed 12:15 PM UTC
Commit: aa1798d · View workflow run →

[fullsend-ai-retro]

Retro: PR #2733 — Add triage-agent to default AllowedRemoteResources

Workflow went smoothly. This was a small (5-line), human-authored configuration PR by ggallen that added the triage-agent URL to the default org allowlist as part of ADR-0045 Phase 2. The review agent approved cleanly in ~12 minutes with no findings. Human reviewer rh-hemartin also approved. No rework cycles. Full test coverage.

One proposal: The retro dispatch logic has a gap — existing skip rules (#2638 for bot PRs with no findings, #2708 for human PRs with no agent involvement) don't cover this case: a human PR where the review agent ran but found nothing. Proposing a unified, verdict-based skip condition.

Existing issues already cover minor observations:

• Empty approval review body → #1046
• Trust boundary / guardrail flagging → #2238 (scoped to agent PRs but conceptually adjacent)

Proposals filed

• Unify retro skip conditions: skip when review verdict is clean approval with no findings (in fullsend-ai/fullsend)

[ralphbean]

cool