FM-4 — sync FORGE_TOOLS_ALLOWLIST with real forge-mcp tool names #808
Labels
No labels
area:agents
area:dashboard
area:database
area:design
area:design-review
area:flows
area:infra
area:meta
area:security
area:sessions
area:webhook
area:workdir
security
type:bug
type:chore
type:meta
type:user-story
No milestone
No project
No assignees
1 participant
dev
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
charles/claude-hooks#808
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
As an operator, I want
FORGE_TOOLS_ALLOWLISTinapps/server/src/domain/agent/mcp-config.tsto list the names thatapps/forge-mcp/src/tools.tsactually registers, so that agents in containers can invokemcp__forge__*tools instead of getting "tool not found" from the SDK allowlist filter and falling back to curl with$FORGEJO_ACCESS_TOKEN.Context — why this is broken today
FM-3 (#687, 2026-05-01) cut over to
forge-mcp(FM-2 hand-rolled bun stdio server,apps/forge-mcp/src/).forge-mcpregisters tools by their short names (get_issue,list_issues,list_pull_requests,submit_review,request_reviewers,read_file,create_comment, …).forge-mcp/src/main.ts:53does a strictbyName.get(name)lookup with no aliasing. MeanwhileFORGE_TOOLS_ALLOWLIST(apps/server/src/domain/agent/mcp-config.ts:75-96) still carries legacy forgejo-mcp names copied from MF-5:get_issue_by_index,list_repo_issues,list_repo_pull_requests,get_pull_request_by_index,list_pull_reviews,create_review_requests,delete_review_requests,get_file_content,create_issue_comment,list_issue_comments. 11 of 17 names mismatch. The SDK'sallowedToolsfilter rejects every call to a realforge-mcpverb. Result: agents have no working forge MCP path and curl-fall-back via$FORGEJO_ACCESS_TOKEN(whichcontainer-reconcile.ts:398injects).This story closes the allowlist drift only. Server-side rename (FM-5) and dualMount rip (FM-6) follow.
Acceptance criteria
Allowlist sync
FORGE_TOOLS_ALLOWLIST(apps/server/src/domain/agent/mcp-config.ts) matches aname:field exported fromapps/forge-mcp/src/tools.tsbuildTools().specs/forge-mcp-cutover-followup.md§"Pass 1":get_issue_by_index→get_issuelist_repo_issues→list_issueslist_issue_comments→list_commentscreate_issue_comment→create_commentlist_repo_pull_requests→list_pull_requestsget_pull_request_by_index→get_pull_requestlist_pull_reviews→list_reviewssubmit_pull_review→submit_reviewcreate_review_requests→request_reviewersdelete_review_requests→remove_review_requestget_file_content→read_fileupdate_issue,add_issue_labels,remove_issue_labels,create_issue,merge_pull_request,create_pull_request,list_repo_labels,list_workflow_runs,get_workflow_run,list_pull_request_filesretained verbatim.Tests
mcp-config.test.ts: every name inFORGE_TOOLS_ALLOWLISTis present in the set returned bybuildTools()fromapps/forge-mcp/src/tools.ts. Cross-package import is fine — same monorepo. The test fails closed if forge-mcp drops or renames a verb.mcp-config.test.tsassertions coveringbuildMcpSetupkeep passing.Manual smoke
mcp__forge__*tool call (e.g.mcp__forge__get_issue,mcp__forge__create_pull_request). Nomcp__forgejo__*tool calls — those will fail because the binary is gone, but they should not be attempted in this story (server-side instructions still emit them; that is FM-5's job to fix).Out of scope
mcp__forgejo__*references inparent-pr.ts,architect.ts,agent-runner.ts,worker.ts— see FM-5.dualMount,forgejoMcpCommand,FORGEJO_TOOLS_ALLOWLIST,FORGEJO_MCP_TOOLSenv wiring — see FM-6.forge-mcp— every verb the agents use today already exists.References
specs/forge-mcp-cutover-followup.md§Pass 1.apps/forge-mcp/src/tools.ts:200-583(name:fields).apps/server/src/domain/agent/mcp-config.ts:75-96.apps/forge-mcp/src/main.ts:53.specs/forge-mcp-multi-forge.md.