Security & operations
Authentication and scope
Grant repository read access deliberately and keep tokens out of shared content.
Client registration and tracker authorization are different steps. The client must be able to launch Toolport; the server must receive a valid tracker credential; that credential must be permitted to read the requested repository.
Scope of the connection
repo:read is Toolport’s descriptive scope label in this contract. It is not a literal scope guaranteed by every tracker provider. Choose the provider’s least-privilege equivalent and restrict the credential to the repositories you need.
Confirm the repository allowlist before connecting private data.
Check whether the provider supports expiration and revocation.
Use separate credentials for personal evaluation and team automation.
Avoid a broad write-capable token just to make a read-only call pass.
Supplying the token
The local configuration examples use TOOLPORT_TOKEN. Environment forwarding and interactive secret inputs avoid publishing values in shared configuration. A secret stored in a local file is still a secret at rest; use the client and operating system’s supported storage and access controls.
Diagnose access errors
Signal | Next check |
|---|---|
AUTH_REQUIRED | Missing token, expiration or invalid credential. |
ACCESS_DENIED | Repository permission or allowlist. |
INVALID_ARGUMENT | Input schema; changing access will not fix it. |
Check access with a small repository-specific call before sending a long prompt. Do not paste a token into the conversation to “authenticate” the server. Keep the token out of terminal history, screenshots and support logs.
Rotation
Replace the credential in its local source, reload affected connections and verify a read. Revoke the old credential only after deciding which clients still use it. Removing a server entry does not revoke a provider token.