feat(ssh): typed degradation errors for API-dependent commands in ssh-only mode #341
No reviewers
Labels
No labels
breaking
bug
documentation
enhancement
epic
good first issue
help wanted
refactoring
resolution/duplicate
resolution/invalid
resolution/wontfix
security
severity/critical
severity/high
severity/low
severity/medium
status/abandoned
status/blocked
status/needs-decision
status/needs-info
status/needs-verification
testing
upstream
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
sixfold-space/madtea!341
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "worktree-issue-295-ssh-typed-degradation"
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?
Summary
In ssh-only mode every command that needs the Forgejo/Gitea REST API fails with one typed service-level error: it names the operation, states that the operation rides the HTTPS REST API which ssh-only mode cannot carry because no token is stored or used, and gives the auth login remedy. GateAPIAccess is the single gate every client-construction path calls, so the degradation is one mechanism - CLI commands (the error sink stamps the command path), MCP tools, the raw api passthrough on both surfaces, and orchestrate's run and reconcile entry points all funnel through it. A leftover stored token is never used; https, ssh, and unset modes are proven unchanged, and pure-git commands are pinned unaffected.
An ssh-only login now counts as configured, so commands reach the typed error instead of the generic not-configured text, and a login re-run offers reconfigure instead of first-time setup. The MCP banner reports ssh-only mode as working-as-designed git-only operation instead of warning about missing credentials, even with a leftover token present.
Closes #295.
Closes #295