✨🧑‍💻 - Account Type Label

[efraespada]

Is there an existing issue or feature request for this?

• I have searched the existing issues and feature requests.

What area does this improvement affect?

Other

Which parts of Cursor Quota does this affect?

Configuration

Description of the idea or improvement

We should include a label on every account item (on the account selection area) to indicate the kind of account.

Current limitations or challenges

None

Expected impact

Easy way to identify accounts.

Alternatives considered

No response

Cursor Quota Version

No response

Additional context or comments

No response

[vypbot]

🪄 Automatic Actions

1. The issue was assigned to @efraespada (creator).
2. The issue's title was updated from Account Type Label to ✨ - Account Type Label.
3. The issue was linked to vypdev and moved to the column Todo.
4. Priority set to P2 in vypdev.
5. Recommended steps (OpenCode Plan agent):
6. Now I have a complete understanding of the project. Here are the recommended implementation steps.

---

Implementation Steps: Account Type Labels

1. Research account type signals in JWT

Examine the decoded JWT payload (from tokenReader.ts:78-89) for claims that indicate auth provider/account kind — typical Auth0 claims like sub prefix (github|, google-oauth2|, auth0|), aud, iss, or custom https://cursor.sh/* claims.

• Run the extension locally, decode the access token (there's already a decodeJwtPayload function at src/auth/tokenReader.ts:78), and log the full payload to discover available provider signals.
• Also search the state.vscdb SQLite database for additional keys beyond the three in CURSOR_AUTH_KEYS (cursorPaths.ts:39-43) that might indicate account type (e.g., GitHub vs Google vs email auth, or plan tier).

2. Add accountKind field to the data model

File: src/api/types.ts

Add a field (e.g., accountKind?: string) to both CursorAuthTokens and QuotaUsage. Use a union type if the possible values are known:

export type AccountKind = 'github' | 'google' | 'email' | 'sso' | 'unknown';

export interface CursorAuthTokens {
  accessToken: string;
  refreshToken?: string;
  email?: string;
  accountKind?: AccountKind;
}

export interface QuotaUsage {
  // ...existing fields...
  accountEmail?: string;
  accountKind?: AccountKind;
  // ...
}

3. Derive account kind from token data

File: src/auth/tokenReader.ts

• Create a new function deriveAccountKind(token: string): AccountKind that decodes the JWT and inspects the sub claim prefix (e.g., github|12345 → 'github', google-oauth2|... → 'google') or any custom provider claim.
• Update readAuthFromStateDb() to call deriveAccountKind and include the result in the returned CursorAuthTokens.

4. Wire accountKind through QuotaClient

File: src/api/quotaClient.ts

• Update mapUsageResponse to accept and forward accountKind?: AccountKind.
• Update QuotaClient.getUsage() to pass tokens.accountKind into mapUsageResponse.

5. Show the label in the status bar tooltip

File: src/ui/statusBarManager.ts

• In buildTooltip(), add a line showing the account kind (e.g., **Account:** GitHub (user@example.com) or **Kind:** GitHub).
• Consider adding a new config setting statusBar.showAccountKind (default true) for users who want to hide it, following the same pattern as showAccountEmail in src/config.ts.

6. Register the new setting

File: package.json (under contributes.configuration.properties)

Add:

"cursorQuota.statusBar.showAccountKind": {
  "type": "boolean",
  "default": true,
  "description": "Show account type label (GitHub, Google, etc.) in status bar tooltips."
}

File: src/config.ts

Add showAccountKind: boolean to CursorQuotaConfig and read it from config.

7. Write tests

File: src/test/tokenReader.test.ts (new or extend existing)

• Test deriveAccountKind with various mock JWT payloads (different sub prefixes, missing sub, etc.).
• Test that readAuthFromStateDb returns the correct accountKind.

File: src/test/quotaClient.test.ts

• Extend mapUsageResponse tests to verify accountKind is correctly passed through.

8. Run tests and type-check

pnpm run lint    # tsc --noEmit
pnpm test        # node --test out/test/*.test.js

9. Update README

Document the new statusBar.showAccountKind setting and what account types are recognized.

Debug log

[DEBUG] Setup done. Issue number: 1, isSingleAction: false, isIssue: true, isPullRequest: false, isPush: false
[DEBUG] ✅ No previous runs active. Continuing...
[INFO] Running IssueUseCase for issue #1.
[INFO] 📋 Executing IssueUseCase.
[INFO] 🔐 Executing CheckPermissionsUseCase.
[DEBUG] Ignoring permission checking. Issue doesn't require mandatory branch.
[INFO] 👤 Executing AssignMemberToIssueUseCase.
[DEBUG] #1 needs 1 assignees.
[DEBUG] Assigned Issue creator @efraespada to #1.
[INFO] ✏️ Executing UpdateTitleUseCase.
[DEBUG] Issue title updated to: ✨ - Account Type Label
[INFO] 🏷️ Executing UpdateIssueTypeUseCase.
[DEBUG] Setting issue type for issue 1 to Feature
[DEBUG] Creating new issue type "Feature" for organization vypdev...
[DEBUG] Issue Type: Feature
[DEBUG] Issue Type Description: A new functionality, enhancement, or improvement requested for the project.
[DEBUG] Issue Type Color: green
[DEBUG] Fetched issue ID: I_kwDOSpY2Fc8AAAABEC-nnA
[DEBUG] Organization ID: MDEyOk9yZ2FuaXphdGlvbjYzNzA1NDAz
[DEBUG] Organization issue types: [{"id":"IT_kwDOA8wRO84AuWac","name":"Task"},{"id":"IT_kwDOA8wRO84AuWag","name":"Bug"},{"id":"IT_kwDOA8wRO84AuWak","name":"Feature"},{"id":"IT_kwDOA8wRO84Bw9l2","name":"Documentation"},{"id":"IT_kwDOA8wRO84Bw9mw","name":"Question"},{"id":"IT_kwDOA8wRO84Bw9oA","name":"Maintenance"},{"id":"IT_kwDOA8wRO84Bw90_","name":"Release"},{"id":"IT_kwDOA8wRO84Bxfgg","name":"Hotfix"},{"id":"IT_kwDOA8wRO84Bxfgh","name":"Help"}]
[DEBUG] Found existing issue type "Feature" with ID: IT_kwDOA8wRO84AuWak
[DEBUG] Successfully updated issue type to Feature
[INFO] 🔗 Executing LinkIssueProjectUseCase.
[DEBUG] Fetched issue ID: I_kwDOSpY2Fc8AAAABEC-nnA
[DEBUG] Linked I_kwDOSpY2Fc8AAAABEC-nnA with id PVTI_lADOA8wRO84Ajh7BzgubHaE to project PVT_kwDOA8wRO84Ajh7B
[DEBUG] Content ID: PVTI_lADOA8wRO84Ajh7BzgubHaE
[DEBUG] Target field: {
  "id": "PVTSSF_lADOA8wRO84Ajh7Bzgb4L2E",
  "name": "Status",
  "options": [
    {
      "id": "f75ad846",
      "name": "Todo"
    },
    {
      "id": "47fc9ee4",
      "name": "In Progress"
    },
    {
      "id": "98236657",
      "name": "Done"
    }
  ]
}
[DEBUG] Target option: {
  "id": "f75ad846",
  "name": "Todo"
}
[DEBUG] Target field ID: PVTSSF_lADOA8wRO84Ajh7Bzgb4L2E
[DEBUG] Target option ID: f75ad846
[INFO] 📏 Executing CheckPriorityIssueSizeUseCase.
[DEBUG] Priority: priority: low
[DEBUG] Github Priority Label: P2
[DEBUG] Content ID: PVTI_lADOA8wRO84Ajh7BzgubHaE
[DEBUG] Target field: {
  "id": "PVTSSF_lADOA8wRO84Ajh7Bzgb4MPQ",
  "name": "Priority",
  "options": [
    {
      "id": "4af6496f",
      "name": "P0"
    },
    {
      "id": "f87877a5",
      "name": "P1"
    },
    {
      "id": "27f99ddc",
      "name": "P2"
    }
  ]
}
[DEBUG] Target option: {
  "id": "27f99ddc",
  "name": "P2"
}
[DEBUG] Target field ID: PVTSSF_lADOA8wRO84Ajh7Bzgb4MPQ
[DEBUG] Target option ID: 27f99ddc
[INFO] 🧹 Executing RemoveIssueBranchesUseCase.
[DEBUG] Checking branch type feature
[DEBUG] Checking prefix feature/1-
[DEBUG] Checking branch type bugfix
[DEBUG] Checking prefix bugfix/1-
[INFO] 🧹 Executing RemoveNotNeededBranchesUseCase.
[INFO] 🏷️ Executing DeployAddedUseCase.
[INFO] 🏷️ Executing DeployedAddedUseCase.
[INFO] 💡 Executing RecommendStepsUseCase.
[DEBUG] RecommendSteps: prompt length=1470, issue description length=634.
[INFO] 🤖 Recommending steps using OpenCode Plan agent...
[INFO] OpenCode request [agent build] model=opencode/deepseek-v4-flash-free promptLength=1470
[INFO] OpenCode sending prompt (full):
Based on the following issue description, recommend concrete steps to implement or address this issue. Order the steps logically (e.g. setup, implementation, tests, docs). Keep each step clear and actionable.

**Important – use full project context:** In addition to reading the relevant code (respecting any file ignore patterns specified), read the repository documentation (e.g. README, docs/) and any defined rules or conventions (e.g. .cursor/rules, CONTRIBUTING, project guidelines). This gives you a complete picture of the project and leads to better decisions in both quality of reasoning and efficiency.

**Issue #1 description:**
### Is there an existing issue or feature request for this?

- [x] I have searched the existing issues and feature requests.

### What area does this improvement affect?

Other

### Which parts of Cursor Quota does this affect?

Configuration

### Description of the idea or improvement

We should include a label on every account item (on the account selection area) to indicate the kind of account.

### Current limitations or challenges

None

### Expected impact

Easy way to identify accounts.

### Alternatives considered

_No response_

### Cursor Quota Version

_No response_

### Additional context or comments

_No response_

Provide a numbered list of recommended steps in **markdown** (use headings, lists, code blocks for commands or snippets) so it is easy to read. You can add brief sub-bullets per step if needed.
[DEBUG] OpenCode prompt (full, no truncation):
Based on the following issue description, recommend concrete steps to implement or address this issue. Order the steps logically (e.g. setup, implementation, tests, docs). Keep each step clear and actionable.

**Important – use full project context:** In addition to reading the relevant code (respecting any file ignore patterns specified), read the repository documentation (e.g. README, docs/) and any defined rules or conventions (e.g. .cursor/rules, CONTRIBUTING, project guidelines). This gives you a complete picture of the project and leads to better decisions in both quality of reasoning and efficiency.

**Issue #1 description:**
### Is there an existing issue or feature request for this?

- [x] I have searched the existing issues and feature requests.

### What area does this improvement affect?

Other

### Which parts of Cursor Quota does this affect?

Configuration

### Description of the idea or improvement

We should include a label on every account item (on the account selection area) to indicate the kind of account.

### Current limitations or challenges

None

### Expected impact

Easy way to identify accounts.

### Alternatives considered

_No response_

### Cursor Quota Version

_No response_

### Additional context or comments

_No response_

Provide a numbered list of recommended steps in **markdown** (use headings, lists, code blocks for commands or snippets) so it is easy to read. You can add brief sub-bullets per step if needed.
[DEBUG] OpenCode message body: agent=build, model=opencode/deepseek-v4-flash-free, parts[0].text length=1470
[DEBUG] OpenCode session create body: {"title":"copilot"}
[DEBUG] OpenCode response [OpenCode session.create] status=200 bodyLength=370. Full body:
{"id":"ses_17aeb8ed2ffeaucFOBycXUxioC","slug":"gentle-harbor","projectID":"5aba452da72ca7389db980e22b9bbd164856e4f4","directory":"/home/runner/work/cursor-accounts/cursor-accounts","path":"","cost":0,"tokens":{"input":0,"output":0,"reasoning":0,"cache":{"read":0,"write":0}},"title":"copilot","version":"1.15.13","time":{"created":1780349169966,"updated":1780349169966}}
[DEBUG] OpenCode POST /session/ses_17aeb8ed2ffeaucFOBycXUxioC/message body (keys): agent, model, parts (1 part(s))
[INFO] OpenCode: waiting for agent "build" message response (client timeout: 15 min)...
[DEBUG] OpenCode response [OpenCode agent "build" message] status=200 bodyLength=7968. Full body:
{"info":{"parentID":"msg_e85147162001r1j0SDWGaHg6z3","role":"assistant","mode":"build","agent":"build","path":{"cwd":"/home/runner/work/cursor-accounts/cursor-accounts","root":"/home/runner/work/cursor-accounts/cursor-accounts"},"cost":0,"tokens":{"total":24618,"input":1929,"output":933,"reasoning":636,"cache":{"write":0,"read":21120}},"modelID":"deepseek-v4-flash-free","providerID":"opencode","time":{"created":1780349227408,"completed":1780349241184},"finish":"stop","id":"msg_e85155190001zHFzHwq5Dx2lnu","sessionID":"ses_17aeb8ed2ffeaucFOBycXUxioC"},"parts":[{"snapshot":"db7523ab632dd9045270ce553c5b7a682be8ccd2","type":"step-start","id":"prt_e85155451001H81QXoVNH7XJBl","sessionID":"ses_17aeb8ed2ffeaucFOBycXUxioC","messageID":"msg_e85155190001zHFzHwq5Dx2lnu"},{"type":"reasoning","text":"Now I have a complete understanding of the project. Let me synthesize my findings and provide concrete implementation steps.\n\nThe issue asks: \"We should include a label on every account item (on the account selection area) to indicate the kind of account.\"\n\nKey observations:\n1. This project does **not** have an account selection area or account items at all - it's a simple status bar extension.\n2. The only \"account\" concept is a single email string from the locally logged-in Cursor account.\n3. There is no \"account type/kind\" anywhere in the codebase.\n\nSo the issue requires:\n1. First, understanding what \"kinds\" of accounts exist for Cursor (from JWT payload or other heuristics)\n2. Adding an account type field to the data model\n3. Detecting/deriving the account type\n4. Adding the label to the UI (likely the tooltip, since there's no account selection area)\n\nWait - the issue says \"account selection area\" which suggests the author might be envisioning a future feature, or perhaps they're confused about what exists. But the task is to recommend steps, so I should work with what exists and propose practical steps.\n\nThe most practical approach would be:\n1. Determine account type from the JWT access token payload (looking at the decoded JWT for things like `sub`, `aud`, issuer info, or custom claims that indicate auth provider)\n2. Add a field like `accountProvider` or `accountKind` to the `CursorAuthTokens` and `QuotaUsage` interfaces\n3. Derive the account type in `tokenReader.ts` when reading auth data\n4. Show the label in the status bar tooltip (alongside or instead of the email)\n\nPossible account types based on Cursor auth (from research docs):\n- GitHub OAuth\n- Google OAuth\n- Email/password\n- SSO (Enterprise)\n- Possibly \"Free\" vs \"Pro\" vs \"Business\" plan type\n\nLet me look more carefully at the JWT structure to see if there's any indication of account type. The `decodeJwtPayload` function already exists. I should check what claims are available.\n\nActually, I think the most practical implementation would be:\n1. Look at the JWT payload claims for hints about the auth provider (e.g., `aud`, `iss`, custom claims like `https://cursor.sh/auth/provider`)\n2. Also look at whether there are additional SQLite keys that could give account type info\n3. Implement a heuristic to determine the account \"kind\"\n\nBut wait - I don't have access to actual JWT tokens to know what claims they contain. However, based on the OAuth flow shown in the code, the client ID is `KbZUR41cY7W6zRSdpSUJ7I7mLYBKOCmB` which is an Auth0 client. Auth0 typically puts the identity provider info in the JWT.\n\nLet me now write up concrete steps based on what I know. Let me check the README as well for any additional context.","time":{"start":1780349228613,"end":1780349234416},"id":"prt_e851556450011QqFPsQPmSbZXY","sessionID":"ses_17aeb8ed2ffeaucFOBycXUxioC","messageID":"msg_e85155190001zHFzHwq5Dx2lnu"},{"type":"text","text":"Now I have a complete understanding of the project. Here are the recommended implementation steps.\n\n---\n\n## Implementation Steps: Account Type Labels\n\n### 1. Research account type signals in JWT\n\nExamine the decoded JWT payload (from `tokenReader.ts:78-89`) for claims that indicate auth provider/account kind — typical Auth0 claims like `sub` prefix (`github|`, `google-oauth2|`, `auth0|`), `aud`, `iss`, or custom `https://cursor.sh/*` claims.\n\n- Run the extension locally, decode the access token (there's already a `decodeJwtPayload` function at `src/auth/tokenReader.ts:78`), and log the full payload to discover available provider signals.\n- Also search the `state.vscdb` SQLite database for additional keys beyond the three in `CURSOR_AUTH_KEYS` (`cursorPaths.ts:39-43`) that might indicate account type (e.g., GitHub vs Google vs email auth, or plan tier).\n\n### 2. Add `accountKind` field to the data model\n\n**File:** `src/api/types.ts`\n\nAdd a field (e.g., `accountKind?: string`) to both `CursorAuthTokens` and `QuotaUsage`. Use a union type if the possible values are known:\n\ntypescript\nexport type AccountKind = 'github' | 'google' | 'email' | 'sso' | 'unknown';\n\nexport interface CursorAuthTokens {\n  accessToken: string;\n  refreshToken?: string;\n  email?: string;\n  accountKind?: AccountKind;\n}\n\nexport interface QuotaUsage {\n  // ...existing fields...\n  accountEmail?: string;\n  accountKind?: AccountKind;\n  // ...\n}\n\n\n### 3. Derive account kind from token data\n\n**File:** `src/auth/tokenReader.ts`\n\n- Create a new function `deriveAccountKind(token: string): AccountKind` that decodes the JWT and inspects the `sub` claim prefix (e.g., `github|12345` → `'github'`, `google-oauth2|...` → `'google'`) or any custom provider claim.\n- Update `readAuthFromStateDb()` to call `deriveAccountKind` and include the result in the returned `CursorAuthTokens`.\n\n### 4. Wire accountKind through QuotaClient\n\n**File:** `src/api/quotaClient.ts`\n\n- Update `mapUsageResponse` to accept and forward `accountKind?: AccountKind`.\n- Update `QuotaClient.getUsage()` to pass `tokens.accountKind` into `mapUsageResponse`.\n\n### 5. Show the label in the status bar tooltip\n\n**File:** `src/ui/statusBarManager.ts`\n\n- In `buildTooltip()`, add a line showing the account kind (e.g., `**Account:** GitHub (user@example.com)` or `**Kind:** GitHub`).\n- Consider adding a new config setting `statusBar.showAccountKind` (default `true`) for users who want to hide it, following the same pattern as `showAccountEmail` in `src/config.ts`.\n\n### 6. Register the new setting\n\n**File:** `package.json` (under `contributes.configuration.properties`)\n\nAdd:\n\njson\n\"cursorQuota.statusBar.showAccountKind\": {\n  \"type\": \"boolean\",\n  \"default\": true,\n  \"description\": \"Show account type label (GitHub, Google, etc.) in status bar tooltips.\"\n}\n\n\n**File:** `src/config.ts`\n\nAdd `showAccountKind: boolean` to `CursorQuotaConfig` and read it from config.\n\n### 7. Write tests\n\n**File:** `src/test/tokenReader.test.ts` (new or extend existing)\n\n- Test `deriveAccountKind` with various mock JWT payloads (different `sub` prefixes, missing `sub`, etc.).\n- Test that `readAuthFromStateDb` returns the correct `accountKind`.\n\n**File:** `src/test/quotaClient.test.ts`\n\n- Extend `mapUsageResponse` tests to verify `accountKind` is correctly passed through.\n\n### 8. Run tests and type-check\n\nbash\npnpm run lint    # tsc --noEmit\npnpm test        # node --test out/test/*.test.js\n\n\n### 9. Update README\n\nDocument the new `statusBar.showAccountKind` setting and what account types are recognized.","time":{"start":1780349234419,"end":1780349241132},"id":"prt_e85156cf3001T13mkSW7I7NmYW","sessionID":"ses_17aeb8ed2ffeaucFOBycXUxioC","messageID":"msg_e85155190001zHFzHwq5Dx2lnu"},{"reason":"stop","snapshot":"db7523ab632dd9045270ce553c5b7a682be8ccd2","type":"step-finish","tokens":{"total":24618,"input":1929,"output":933,"reasoning":636,"cache":{"write":0,"read":21120}},"cost":0,"id":"prt_e8515874b001L8d05wQ2sxvZGs","sessionID":"ses_17aeb8ed2ffeaucFOBycXUxioC","messageID":"msg_e85155190001zHFzHwq5Dx2lnu"}]}
[DEBUG] OpenCode agent "build" message parts: 4 part(s) — [0] type=step-start length=0 | [1] type=reasoning length=2722 | [2] type=text length=3566 | [3] type=step-finish length=0
[DEBUG] OpenCode part [1] type=reasoning full text:
Now I have a complete understanding of the project. Let me synthesize my findings and provide concrete implementation steps.

The issue asks: "We should include a label on every account item (on the account selection area) to indicate the kind of account."

Key observations:
1. This project does **not** have an account selection area or account items at all - it's a simple status bar extension.
2. The only "account" concept is a single email string from the locally logged-in Cursor account.
3. There is no "account type/kind" anywhere in the codebase.

So the issue requires:
1. First, understanding what "kinds" of accounts exist for Cursor (from JWT payload or other heuristics)
2. Adding an account type field to the data model
3. Detecting/deriving the account type
4. Adding the label to the UI (likely the tooltip, since there's no account selection area)

Wait - the issue says "account selection area" which suggests the author might be envisioning a future feature, or perhaps they're confused about what exists. But the task is to recommend steps, so I should work with what exists and propose practical steps.

The most practical approach would be:
1. Determine account type from the JWT access token payload (looking at the decoded JWT for things like `sub`, `aud`, issuer info, or custom claims that indicate auth provider)
2. Add a field like `accountProvider` or `accountKind` to the `CursorAuthTokens` and `QuotaUsage` interfaces
3. Derive the account type in `tokenReader.ts` when reading auth data
4. Show the label in the status bar tooltip (alongside or instead of the email)

Possible account types based on Cursor auth (from research docs):
- GitHub OAuth
- Google OAuth
- Email/password
- SSO (Enterprise)
- Possibly "Free" vs "Pro" vs "Business" plan type

Let me look more carefully at the JWT structure to see if there's any indication of account type. The `decodeJwtPayload` function already exists. I should check what claims are available.

Actually, I think the most practical implementation would be:
1. Look at the JWT payload claims for hints about the auth provider (e.g., `aud`, `iss`, custom claims like `https://cursor.sh/auth/provider`)
2. Also look at whether there are additional SQLite keys that could give account type info
3. Implement a heuristic to determine the account "kind"

But wait - I don't have access to actual JWT tokens to know what claims they contain. However, based on the OAuth flow shown in the code, the client ID is `KbZUR41cY7W6zRSdpSUJ7I7mLYBKOCmB` which is an Auth0 client. Auth0 typically puts the identity provider info in the JWT.

Let me now write up concrete steps based on what I know. Let me check the README as well for any additional context.
[DEBUG] OpenCode part [2] type=text full text:
Now I have a complete understanding of the project. Here are the recommended implementation steps.

---

## Implementation Steps: Account Type Labels

### 1. Research account type signals in JWT

Examine the decoded JWT payload (from `tokenReader.ts:78-89`) for claims that indicate auth provider/account kind — typical Auth0 claims like `sub` prefix (`github|`, `google-oauth2|`, `auth0|`), `aud`, `iss`, or custom `https://cursor.sh/*` claims.

- Run the extension locally, decode the access token (there's already a `decodeJwtPayload` function at `src/auth/tokenReader.ts:78`), and log the full payload to discover available provider signals.
- Also search the `state.vscdb` SQLite database for additional keys beyond the three in `CURSOR_AUTH_KEYS` (`cursorPaths.ts:39-43`) that might indicate account type (e.g., GitHub vs Google vs email auth, or plan tier).

### 2. Add `accountKind` field to the data model

**File:** `src/api/types.ts`

Add a field (e.g., `accountKind?: string`) to both `CursorAuthTokens` and `QuotaUsage`. Use a union type if the possible values are known:

typescript
export type AccountKind = 'github' | 'google' | 'email' | 'sso' | 'unknown';

export interface CursorAuthTokens {
  accessToken: string;
  refreshToken?: string;
  email?: string;
  accountKind?: AccountKind;
}

export interface QuotaUsage {
  // ...existing fields...
  accountEmail?: string;
  accountKind?: AccountKind;
  // ...
}


### 3. Derive account kind from token data

**File:** `src/auth/tokenReader.ts`

- Create a new function `deriveAccountKind(token: string): AccountKind` that decodes the JWT and inspects the `sub` claim prefix (e.g., `github|12345` → `'github'`, `google-oauth2|...` → `'google'`) or any custom provider claim.
- Update `readAuthFromStateDb()` to call `deriveAccountKind` and include the result in the returned `CursorAuthTokens`.

### 4. Wire accountKind through QuotaClient

**File:** `src/api/quotaClient.ts`

- Update `mapUsageResponse` to accept and forward `accountKind?: AccountKind`.
- Update `QuotaClient.getUsage()` to pass `tokens.accountKind` into `mapUsageResponse`.

### 5. Show the label in the status bar tooltip

**File:** `src/ui/statusBarManager.ts`

- In `buildTooltip()`, add a line showing the account kind (e.g., `**Account:** GitHub (user@example.com)` or `**Kind:** GitHub`).
- Consider adding a new config setting `statusBar.showAccountKind` (default `true`) for users who want to hide it, following the same pattern as `showAccountEmail` in `src/config.ts`.

### 6. Register the new setting

**File:** `package.json` (under `contributes.configuration.properties`)

Add:

json
"cursorQuota.statusBar.showAccountKind": {
  "type": "boolean",
  "default": true,
  "description": "Show account type label (GitHub, Google, etc.) in status bar tooltips."
}


**File:** `src/config.ts`

Add `showAccountKind: boolean` to `CursorQuotaConfig` and read it from config.

### 7. Write tests

**File:** `src/test/tokenReader.test.ts` (new or extend existing)

- Test `deriveAccountKind` with various mock JWT payloads (different `sub` prefixes, missing `sub`, etc.).
- Test that `readAuthFromStateDb` returns the correct `accountKind`.

**File:** `src/test/quotaClient.test.ts`

- Extend `mapUsageResponse` tests to verify `accountKind` is correctly passed through.

### 8. Run tests and type-check

bash
pnpm run lint    # tsc --noEmit
pnpm test        # node --test out/test/*.test.js


### 9. Update README

Document the new `statusBar.showAccountKind` setting and what account types are recognized.
[INFO] OpenCode response [agent build] responseLength=3566 sessionId=ses_17aeb8ed2ffeaucFOBycXUxioC
[DEBUG] RecommendSteps: OpenCode response received. Steps length=3566. Full steps:
Now I have a complete understanding of the project. Here are the recommended implementation steps.

---

## Implementation Steps: Account Type Labels

### 1. Research account type signals in JWT

Examine the decoded JWT payload (from `tokenReader.ts:78-89`) for claims that indicate auth provider/account kind — typical Auth0 claims like `sub` prefix (`github|`, `google-oauth2|`, `auth0|`), `aud`, `iss`, or custom `https://cursor.sh/*` claims.

- Run the extension locally, decode the access token (there's already a `decodeJwtPayload` function at `src/auth/tokenReader.ts:78`), and log the full payload to discover available provider signals.
- Also search the `state.vscdb` SQLite database for additional keys beyond the three in `CURSOR_AUTH_KEYS` (`cursorPaths.ts:39-43`) that might indicate account type (e.g., GitHub vs Google vs email auth, or plan tier).

### 2. Add `accountKind` field to the data model

**File:** `src/api/types.ts`

Add a field (e.g., `accountKind?: string`) to both `CursorAuthTokens` and `QuotaUsage`. Use a union type if the possible values are known:

typescript
export type AccountKind = 'github' | 'google' | 'email' | 'sso' | 'unknown';

export interface CursorAuthTokens {
  accessToken: string;
  refreshToken?: string;
  email?: string;
  accountKind?: AccountKind;
}

export interface QuotaUsage {
  // ...existing fields...
  accountEmail?: string;
  accountKind?: AccountKind;
  // ...
}


### 3. Derive account kind from token data

**File:** `src/auth/tokenReader.ts`

- Create a new function `deriveAccountKind(token: string): AccountKind` that decodes the JWT and inspects the `sub` claim prefix (e.g., `github|12345` → `'github'`, `google-oauth2|...` → `'google'`) or any custom provider claim.
- Update `readAuthFromStateDb()` to call `deriveAccountKind` and include the result in the returned `CursorAuthTokens`.

### 4. Wire accountKind through QuotaClient

**File:** `src/api/quotaClient.ts`

- Update `mapUsageResponse` to accept and forward `accountKind?: AccountKind`.
- Update `QuotaClient.getUsage()` to pass `tokens.accountKind` into `mapUsageResponse`.

### 5. Show the label in the status bar tooltip

**File:** `src/ui/statusBarManager.ts`

- In `buildTooltip()`, add a line showing the account kind (e.g., `**Account:** GitHub (user@example.com)` or `**Kind:** GitHub`).
- Consider adding a new config setting `statusBar.showAccountKind` (default `true`) for users who want to hide it, following the same pattern as `showAccountEmail` in `src/config.ts`.

### 6. Register the new setting

**File:** `package.json` (under `contributes.configuration.properties`)

Add:

json
"cursorQuota.statusBar.showAccountKind": {
  "type": "boolean",
  "default": true,
  "description": "Show account type label (GitHub, Google, etc.) in status bar tooltips."
}


**File:** `src/config.ts`

Add `showAccountKind: boolean` to `CursorQuotaConfig` and read it from config.

### 7. Write tests

**File:** `src/test/tokenReader.test.ts` (new or extend existing)

- Test `deriveAccountKind` with various mock JWT payloads (different `sub` prefixes, missing `sub`, etc.).
- Test that `readAuthFromStateDb` returns the correct `accountKind`.

**File:** `src/test/quotaClient.test.ts`

- Extend `mapUsageResponse` tests to verify `accountKind` is correctly passed through.

### 8. Run tests and type-check

bash
pnpm run lint    # tsc --noEmit
pnpm test        # node --test out/test/*.test.js


### 9. Update README

Document the new `statusBar.showAccountKind` setting and what account types are recognized.
[INFO] Main run finished. Results: 8, total steps: 6.
[INFO] Publishing result: 8 result(s), 6 step(s), 0 error(s).
[INFO] 📄 Executing PublishResultUseCase.

🚀 Happy coding!

^{Made with ❤️ by vypdev/copilot}

[vypbot]

✨ Feature Actions

1. The issue's title was updated from ✨ - Account Type Label to ✨🧑‍💻 - Account Type Label.
2. The branch develop was used to create feature/1-account-type-label.
3. Moved issue to In Progress in vypdev.

Reminder

1. Take a coffee break while you work ☕.
2. Check out the branch:

git fetch -v && git checkout feature/1-account-type-label

3. Commit the needed changes with this prefix:

feature-1-account-type-label

4. Open a Pull Request from feature/1-account-type-label to develop. New PR

Debug log

[DEBUG] Setup done. Issue number: 1, isSingleAction: false, isIssue: true, isPullRequest: false, isPush: false
[DEBUG] ✅ No previous runs active. Continuing...
[INFO] Running IssueUseCase for issue #1.
[INFO] 📋 Executing IssueUseCase.
[INFO] 🔐 Executing CheckPermissionsUseCase.
[DEBUG] Ignoring permission checking. Issue state is not 'opened'.
[INFO] 👤 Executing AssignMemberToIssueUseCase.
[DEBUG] #1 needs 1 assignees.
[INFO] ✏️ Executing UpdateTitleUseCase.
[DEBUG] Issue title updated to: ✨🧑‍💻 - Account Type Label
[INFO] 🏷️ Executing UpdateIssueTypeUseCase.
[DEBUG] Setting issue type for issue 1 to Feature
[DEBUG] Creating new issue type "Feature" for organization vypdev...
[DEBUG] Issue Type: Feature
[DEBUG] Issue Type Description: A new functionality, enhancement, or improvement requested for the project.
[DEBUG] Issue Type Color: green
[DEBUG] Fetched issue ID: I_kwDOSpY2Fc8AAAABEC-nnA
[DEBUG] Organization ID: MDEyOk9yZ2FuaXphdGlvbjYzNzA1NDAz
[DEBUG] Organization issue types: [{"id":"IT_kwDOA8wRO84AuWac","name":"Task"},{"id":"IT_kwDOA8wRO84AuWag","name":"Bug"},{"id":"IT_kwDOA8wRO84AuWak","name":"Feature"},{"id":"IT_kwDOA8wRO84Bw9l2","name":"Documentation"},{"id":"IT_kwDOA8wRO84Bw9mw","name":"Question"},{"id":"IT_kwDOA8wRO84Bw9oA","name":"Maintenance"},{"id":"IT_kwDOA8wRO84Bw90_","name":"Release"},{"id":"IT_kwDOA8wRO84Bxfgg","name":"Hotfix"},{"id":"IT_kwDOA8wRO84Bxfgh","name":"Help"}]
[DEBUG] Found existing issue type "Feature" with ID: IT_kwDOA8wRO84AuWak
[DEBUG] Successfully updated issue type to Feature
[INFO] 🔗 Executing LinkIssueProjectUseCase.
[DEBUG] Fetched issue ID: I_kwDOSpY2Fc8AAAABEC-nnA
[DEBUG] Content I_kwDOSpY2Fc8AAAABEC-nnA is already linked to project PVT_kwDOA8wRO84Ajh7B.
[DEBUG] LinkIssueProject: issue already linked to project "vypdev" or link failed.
[INFO] 📏 Executing CheckPriorityIssueSizeUseCase.
[DEBUG] Priority: priority: low
[DEBUG] Github Priority Label: P2
[DEBUG] Content ID: PVTI_lADOA8wRO84Ajh7BzgubHaE
[DEBUG] Target field: {
  "id": "PVTSSF_lADOA8wRO84Ajh7Bzgb4MPQ",
  "name": "Priority",
  "options": [
    {
      "id": "4af6496f",
      "name": "P0"
    },
    {
      "id": "f87877a5",
      "name": "P1"
    },
    {
      "id": "27f99ddc",
      "name": "P2"
    }
  ]
}
[DEBUG] Target option: {
  "id": "27f99ddc",
  "name": "P2"
}
[DEBUG] Field 'Priority' is already set to 'P2'. No update needed.
[INFO] 🌿 Executing PrepareBranchesUseCase.
[DEBUG] Fetching tags and forcing fetch...
[DEBUG] Fetching all remote branches with verbose output...
[DEBUG] Successfully fetched all remote branches.
[DEBUG] Available branches:
[DEBUG] - develop
[DEBUG] - master
[DEBUG] Branch type: feature
[DEBUG] Managing branches
[DEBUG] [
  "develop",
  "master"
]
[DEBUG] Searching for branches related to issue #1...
[DEBUG] ============================================================================================
[DEBUG] Base branch: develop
[DEBUG] New branch: feature/1-account-type-label
[DEBUG] Creating linked branch feature/1-account-type-label from develop
[DEBUG] Repository information retrieved: {"target":{"oid":"5701992c5d42f520fb550a3e88f93145cf5a40a5"}}
[DEBUG] Linking branch "feature/1-account-type-label" (oid: 5701992c5d42f520fb550a3e88f93145cf5a40a5) to issue #1
[DEBUG] Linked branch: {"id":"LB_kwDPAAAAARAvp5zOANeYxw","ref":{"name":"feature/1-account-type-label"}}
[INFO] 📜 Executing CommitPrefixBuilderUseCase.
[DEBUG] Commit prefix generated: feature-1-account-type-label
[INFO] 📥 Executing MoveIssueToInProgressUseCase.
[DEBUG] Content ID: PVTI_lADOA8wRO84Ajh7BzgubHaE
[DEBUG] Target field: {
  "id": "PVTSSF_lADOA8wRO84Ajh7Bzgb4L2E",
  "name": "Status",
  "options": [
    {
      "id": "f75ad846",
      "name": "Todo"
    },
    {
      "id": "47fc9ee4",
      "name": "In Progress"
    },
    {
      "id": "98236657",
      "name": "Done"
    }
  ]
}
[DEBUG] Target option: {
  "id": "47fc9ee4",
  "name": "In Progress"
}
[DEBUG] Target field ID: PVTSSF_lADOA8wRO84Ajh7Bzgb4L2E
[DEBUG] Target option ID: 47fc9ee4
[INFO] 🧹 Executing RemoveNotNeededBranchesUseCase.
[INFO] 🏷️ Executing DeployAddedUseCase.
[INFO] 🏷️ Executing DeployedAddedUseCase.
[INFO] Main run finished. Results: 8, total steps: 3.
[INFO] Publishing result: 8 result(s), 3 step(s), 0 error(s).
[INFO] 📄 Executing PublishResultUseCase.

🚀 Happy coding!

^{Made with ❤️ by vypdev/copilot}

[vypbot]

✨ Feature News

Changes on branch feature/1-account-type-label:

---

• 6ba1d4e by Efra Espada (@efraespada)

Update documentation and localization for storage management features

- Revised ARCHITECTURE.md to include details on the new storage management system, including the addition of storage cleanup services and their orchestration.
- Enhanced COMMANDS.md with descriptions of new file management actions available in the UI, detailing their risks and typical space reclaimed.
- Updated localization files for multiple languages to incorporate new strings related to file management and storage cleanup actions, ensuring a consistent user experience across different languages.

---

⚠️ Attention

One or more commits didn't start with the prefix feature-1-account-type-label.

feature-1-account-type-label: created hello-world app

---

^{Made with ❤️ by vypdev/copilot}