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.
- Replace NewToolWithScopes with updated NewTool that includes scope parameters
- All tools now use the same constructor with explicit scope requirements
- Documentation only shows accepted scopes when they differ from required
- Removed NewToolWithScopes and NewToolFromHandlerWithScopes helper functions
Co-authored-by: SamMorrowDrums <4811358+SamMorrowDrums@users.noreply.github.com>
- Updated all remaining tools with OAuth scope information
- Added scope documentation generation to generate-docs command
- Documentation now shows Required and Accepted OAuth scopes for each tool
- All 100+ tools now have scope information defined
- Tests pass, linter passes, documentation generated successfully
Co-authored-by: SamMorrowDrums <4811358+SamMorrowDrums@users.noreply.github.com>
Adam Holt