chore: add agents repo to allowed_remote_resources

[ggallen]

Summary

• Adds allowed_remote_resources with both https://raw.githubusercontent.com/fullsend-ai/fullsend/ and https://raw.githubusercontent.com/fullsend-ai/agents/

This change is required before fullsend's v0 tag can move to v0.29.0. The new version resolves agent harnesses from fullsend-ai/agents at runtime, and the URL must be in the config allowlist.

No behavioral change on the current v0 (v0.28.0).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[rhdh-qodo-merge]

PR Summary by Qodo

Allow fullsend-ai/agents raw GitHub URL in remote resource allowlist

⚙️ Configuration changes 🕐 Less than 5 minutes

AI Description

• Add an allowed_remote_resources allowlist to .fullsend/config.yaml.
• Permit raw GitHub URLs for fullsend-ai/fullsend and fullsend-ai/agents.
• Unblocks upgrading v0 to v0.29.0 for runtime agent harness resolution.

High-Level Assessment

Approach is appropriate: explicitly allowlisting the exact raw GitHub origins needed for runtime harness resolution is the simplest and most auditable solution. Alternatives (e.g., broader wildcards or proxying downloads) add risk or operational complexity without clear benefit here.

Files changed (1) +3 / -0

Other (1) +3 / -0

config.yamlAllowlist raw GitHub remote resources for harness resolution +3/-0

Allowlist raw GitHub remote resources for harness resolution

• Introduces an 'allowed_remote_resources' section and adds raw GitHub content URLs for the 'fullsend-ai/fullsend' and 'fullsend-ai/agents' repositories. This enables newer runtime behavior that fetches agent harnesses from 'fullsend-ai/agents'.

.fullsend/config.yaml

[rhdh-qodo-merge]

Code Review by Qodo

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

Context used

✅ Compliance rules (platform): 11 rules

1. Docs omit config key 🐞 Bug ⚙ Maintainability

Description

Documentation states .fullsend/config.yaml declares enabled roles, but the PR adds
allowed_remote_resources, making the documentation incomplete and potentially misleading for
future maintenance/security reviews.

Code

.fullsend/config.yaml[R7-9]

+allowed_remote_resources:
+  - https://raw.githubusercontent.com/fullsend-ai/fullsend/
+  - https://raw.githubusercontent.com/fullsend-ai/agents/

Relevance

⭐⭐ Medium

Mixed history: docs updated for config naming in PR #2923, but similar README key mismatch rejected
in PR #2301.

PR-#2923
PR-#2301

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The docs table explicitly defines .fullsend/config.yaml as a roles-only declaration, but the file
now includes an additional top-level key (allowed_remote_resources).

docs/fullsend.md[104-110]
.fullsend/config.yaml[7-9]

Agent prompt

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

### Issue description
`docs/fullsend.md` describes `.fullsend/config.yaml` as only declaring enabled roles, but it now also contains `allowed_remote_resources`.

### Issue Context
Keeping the docs accurate matters because `.fullsend/` is security-sensitive configuration (CODEOWNERS-protected per the docs).

### Fix Focus Areas
- docs/fullsend.md[104-110]
- .fullsend/config.yaml[7-9]

### Proposed fix
Update the config table entry (and/or add a short subsection) to mention `allowed_remote_resources`, what it controls, and why the listed URLs are present.

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

---

2. Overbroad remote allowlist 🐞 Bug ⛨ Security

Description

allowed_remote_resources is configured as repo-root URL prefixes, which implicitly allows fetching
any file from any ref (branch/tag/commit) under those repos, widening the trusted remote content
surface. This makes it harder to audit/lock down exactly what remote resources Fullsend can consume
and increases blast radius if those upstream repos change unexpectedly.

Code

.fullsend/config.yaml[R7-9]

+allowed_remote_resources:
+  - https://raw.githubusercontent.com/fullsend-ai/fullsend/
+  - https://raw.githubusercontent.com/fullsend-ai/agents/

Relevance

⭐ Low

Similar Fullsend security hardening (pin @v0, trust guard, least-privilege) was rejected in PR
#3256.

PR-#3256

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The config change allowlists raw GitHub at the repo root level, which (given raw GitHub URL
structure) allows any ref/path under those repos. The workflow also passes fullsend_ai_ref: v0,
indicating the system is already designed to follow an external ref, so tightening the allowed
remote prefixes helps keep remote consumption auditable.

.fullsend/config.yaml[7-9]
.github/workflows/fullsend.yaml[53-60]

Agent prompt

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

### Issue description
`.fullsend/config.yaml` currently allowlists `https://raw.githubusercontent.com/fullsend-ai/{repo}/` which matches *any* ref and path. This is broader than necessary and makes it difficult to reason about what remote content is permitted.

### Issue Context
GitHub raw URLs follow the pattern `https://raw.githubusercontent.com/<org>/<repo>/<ref>/<path>`. Allowlisting only up to `<repo>/` implicitly allows all `<ref>/<path>` combinations.

### Fix Focus Areas
- .fullsend/config.yaml[7-9]
- .github/workflows/fullsend.yaml[53-60]

### Proposed fix
- Replace the repo-root prefixes with more specific prefixes that include an immutable ref (tag/commit) and, if possible, the exact directory prefix that Fullsend needs (e.g., `.../agents/<pinned-ref>/harness/` rather than `.../agents/`).
- If operationally feasible, also pin `fullsend_ai_ref` to a specific version tag/commit instead of a moving tag to reduce supply-chain drift.

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

---