Build and Test Go Project / build (macos-latest) (push) Has been cancelled
Build and Test Go Project / build (ubuntu-latest) (push) Has been cancelled
Build and Test Go Project / build (windows-latest) (push) Has been cancelled
CodeQL / Analyze (go) (push) Has been cancelled
CodeQL / Analyze (actions) (push) Has been cancelled
- Removed NewServerToolFromHandler function from pkg/inventory/server_tool.go
- Updated test helper functions (mockTool and mockToolWithDefault) to use NewServerToolWithRawContextHandler
- All tests pass successfully
Co-authored-by: SamMorrowDrums <4811358+SamMorrowDrums@users.noreply.github.com>
- Add context-based GraphQL feature flag support
- Modify bearerAuthTransport to read features from context and add GraphQL-Features header
- Use issues_copilot_assignment_api_support feature flag for updateIssue mutation
- Export GetGraphQLFeatures function for use in HTTP transport layer
This allows the assign_copilot_to_issue tool to work with the non-GA agent assignment API
by sending the required GraphQL-Features header.
Co-authored-by: SamMorrowDrums <4811358+SamMorrowDrums@users.noreply.github.com>
- Add optional base_ref parameter to tool schema
- Change from replaceActorsForAssignable to updateIssue mutation with agentAssignment
- Add AgentAssignmentInput and UpdateIssueInput structs for new GraphQL mutation
- Update all tests to use new mutation structure
- Add test case for base_ref functionality
- Update toolsnaps and documentation
Co-authored-by: SamMorrowDrums <4811358+SamMorrowDrums@users.noreply.github.com>
The ForMCPRequest optimization was incorrectly filtering resources by
doing an exact string match between the URI template pattern and the
concrete URI. This would never match because templates like
'repo://{owner}/{repo}/contents{/path*}' don't match concrete URIs
like 'repo://owner/repo/contents/file.py'.
Instead of implementing template matching in the inventory, we simply
keep all resources registered for resources/read requests and let the
SDK handle URI template matching internally (which it already does
correctly via uritemplate.Regexp().MatchString()).
This fixes resources/read returning 'Resource not found' for valid URIs.
The RepositoryResourceContentsHandler was using closure-captured deps
instead of retrieving them from context at call time. This causes issues
on the remote server which injects per-request deps via context.
Changed to use MustDepsFromContext(ctx) pattern consistent with tool
handlers in NewTool and NewToolFromHandler.
The generate-docs command now outputs toolset IDs (e.g., `actions`, `code_security`)
wrapped in backticks instead of display names (e.g., "Actions", "Code Security").
This ensures the manual changes from PR #1756 persist when the docs are regenerated,
fixing the issue where users need to configure the actual toolset ID, not the display name.
Changes:
- Modified generateRemoteToolsetsDoc() to use `idStr` instead of `formattedName()`
- Modified generateRemoteOnlyToolsetsDoc() to use `idStr` instead of `formattedName()`
- Both functions now wrap the toolset ID in backticks for clarity
Co-authored-by: SamMorrowDrums <4811358+SamMorrowDrums@users.noreply.github.com>
The CompleteParams.Context field is optional (marked omitempty) and can be
nil when clients don't send it. The code was accessing Context.Arguments
directly without checking if Context was nil first, causing a panic.
This fix adds a nil check for Context before accessing Arguments.
- Scope filtering only applies to classic PATs which return X-OAuth-Scopes
- Fine-grained PATs and other token types skip filtering (all tools shown)
- Updated docs to clarify PAT filtering vs OAuth scope challenges
Scope filtering is now a built-in feature rather than a configurable option.
The server automatically fetches token scopes at startup and filters tools
accordingly. If scope detection fails, it logs a warning and continues with
all tools available.
Add the ability to filter tools based on token scopes for PAT users.
This uses an HTTP HEAD request to GitHub's API to discover token scopes.
New components:
- pkg/scopes/filter.go: HasRequiredScopes checks if scopes satisfy tool requirements
- pkg/scopes/fetcher.go: FetchTokenScopes gets scopes via HTTP HEAD to GitHub API
- pkg/github/scope_filter.go: CreateScopeFilter creates inventory.ToolFilter
Integration:
- Add --filter-by-scope flag to stdio command (disabled by default)
- When enabled, fetches token scopes on startup
- Tools requiring unavailable scopes are hidden from tool list
- Gracefully continues without filtering if scope fetch fails (logs warning)
This allows the OSS server to have similar scope-based tool visibility
as the remote server, and the filter logic can be reused by remote server.
Map iteration in Go is non-deterministic, which causes doc generation
to produce different output on each run. Sort the scope slices in:
- ScopeSet.ToSlice()
- ScopeSet.ToStringSlice()
- ExpandScopes()
public_repo is implicit - the GitHub API handles the distinction between
public and private repos. Using repo as the required scope is more
consistent with our enforcement model:
- PATs: tools visible if token has repo scope
- OAuth: scope challenge requests repo scope
- Add ScopeHierarchy map defining parent-child scope relationships
- Add ExpandScopes() function to derive accepted scopes from required scopes
- Update NewTool/NewToolFromHandler to take []scopes.Scope and auto-derive AcceptedScopes
- Add new scope constants: NoScope, User, ReadUser, UserEmail, ReadPackages, WritePackages
- Update all tool files to use new signature with typed scopes
- Add comprehensive tests for ExpandScopes
The scope hierarchy allows automatic derivation of accepted scopes:
- repo → public_repo, security_events
- admin:org → write:org → read:org
- project → read:project
- write:packages → read:packages
- user → read:user, user:email
This enables the remote server to consume scope info directly from OSS tools.
copilot-swe-agent[bot]