Summary
Add a bgagent linear remove-workspace <slug> CLI command that lets a Linear-workspace admin deregister a workspace previously onboarded via bgagent linear setup or bgagent linear add-workspace. Surfaced during PR #160 review (krokoko) — tracked as a follow-up that never landed.
Today, removing a workspace requires manual surgery across DDB and Secrets Manager, which is error-prone and undocumented.
Motivation
Workspace onboarding is a one-line CLI command. Workspace removal isn't — operators have to:
- Find the row in
LinearWorkspaceRegistryTable and either delete it or flip status to revoked
- Delete the per-workspace OAuth secret in Secrets Manager (
bgagent-linear-oauth-<slug>)
- (Optional) Clean up
LinearProjectMappingTable rows for that workspace
Without the command, a workspace removal can leave dangling secrets, stale registry rows that the resolver still reads, or orphan project mappings that confuse operators.
Proposed UX
$ bgagent linear remove-workspace acme
Found workspace 'acme' (Linear workspace ID: ws-uuid-1234, status=active)
This will:
• Mark the registry row as status=revoked (preserves audit trail)
• Delete the Secrets Manager secret 'bgagent-linear-oauth-acme'
• Delete 4 project mappings for this workspace
Type the workspace slug to confirm: acme
✔ Registry row revoked
✔ Secret deleted
✔ 4 project mappings removed
Done.
Flags:
--purge — also delete the registry row entirely (default: keep with status=revoked for audit)
--keep-mappings — leave LinearProjectMappingTable rows alone
--yes — skip the slug-confirmation prompt (for scripted use)
Acceptance criteria
Out of scope
- Re-onboarding a previously-revoked workspace (separate issue if needed; today operators can just
bgagent linear add-workspace again)
- UI in any web console — CLI only
References
Estimate
~1–2 hours: handler + CLI command + tests + doc snippet. No infra changes (existing tables and secret prefix are reused).
Summary
Add a
bgagent linear remove-workspace <slug>CLI command that lets a Linear-workspace admin deregister a workspace previously onboarded viabgagent linear setuporbgagent linear add-workspace. Surfaced during PR #160 review (krokoko) — tracked as a follow-up that never landed.Today, removing a workspace requires manual surgery across DDB and Secrets Manager, which is error-prone and undocumented.
Motivation
Workspace onboarding is a one-line CLI command. Workspace removal isn't — operators have to:
LinearWorkspaceRegistryTableand either delete it or flipstatustorevokedbgagent-linear-oauth-<slug>)LinearProjectMappingTablerows for that workspaceWithout the command, a workspace removal can leave dangling secrets, stale registry rows that the resolver still reads, or orphan project mappings that confuse operators.
Proposed UX
Flags:
--purge— also delete the registry row entirely (default: keep withstatus=revokedfor audit)--keep-mappings— leaveLinearProjectMappingTablerows alone--yes— skip the slug-confirmation prompt (for scripted use)Acceptance criteria
bgagent linear remove-workspace <slug>registered undercli/src/commands/linear/DELETE /v1/linear/workspaces/{slug}) — keeps DDB / Secrets Manager grants on the API role, not on every CLI usercdk/src/handlers/linear/that:setupfor that slug — same auth pattern as existing OAuth admin commands)LinearWorkspaceRegistryTablerow tostatus='revoked'(or deletes it with--purge)bgagent-linear-oauth-<slug>secret from Secrets ManagerLinearProjectMappingTablerows whereworkspace_slug = <slug>linear-oauth-resolver.ts+ Python equivalent) treatsstatus='revoked'as fail-closed (already does — re-verify under test)docs/guides/LINEAR_SETUP_GUIDE.mdunder "Removing a workspace"Out of scope
bgagent linear add-workspaceagain)References
cdk/src/constructs/linear-integration.ts, OAuth secret naming convention incdk/src/handlers/shared/linear-oauth-resolver.tsEstimate
~1–2 hours: handler + CLI command + tests + doc snippet. No infra changes (existing tables and secret prefix are reused).