Tell your AI what you want — it knows exactly where it is.
Index your codebase once. Ask real questions in Codex, Cursor, Claude Code, or any MCP-compatible tool — and get answers grounded in real, up-to-date context.
$ curl -fsSL https://storage.tlelabs.com/ctxe/dev/install.sh | sh
zsh — ~/projects/my-app
$ ctxe index .
Indexed 1,284 files (4,872 chunks) in 41s
$ ctxe ask "How does user session refresh work after login?"
Comprehensive Session Refresh Analysis
1. Entry Points
• POST /auth/refresh — src/api/auth/refresh.ts:31
• AuthMiddleware.refreshIfNeeded() — src/middleware/auth.ts:89
• BackgroundTokenRefresher — src/jobs/token-refresh.ts:22
• Mobile SDK refresh handler
2. Core Logic
SessionService.refresh() — src/auth/session.ts:147
- Validates refresh token against Redis + DB
- Enforces single-use rotation by default
- Issues new access token (15m) + refresh token (7d)
- Blacklists previous refresh token
3. Key Dependencies & Relationships
• RefreshTokenRepository (src/db/repositories/refresh-token.ts:18)
• RedisClient (src/infra/redis.ts)
• TokenBlacklistRepository
• UserRepository (lastLoginAt updates)
• JwtService.signAccessToken()
Call graph depth: 4 levels | 17 direct files | 41 indirect files
4. Impact Analysis
Changing refresh strategy affects:
- 14 backend files
- 3 background jobs
- Mobile SDKs (iOS + Android)
- Web frontend auth service
5. Security Recommendations
• Enforce refresh token rotation on every use
• Add device fingerprinting to refresh requests
• Implement refresh token family invalidation
• Add rate limiting + progressive backoff on refresh endpoint
• Improve audit logging for all token events
Analysis complete. Ready for detailed plan.
1. Entry Points
• POST /auth/refresh — src/api/auth/refresh.ts:31
• AuthMiddleware.refreshIfNeeded() — src/middleware/auth.ts:89
• BackgroundTokenRefresher — src/jobs/token-refresh.ts:22
• Mobile SDK refresh handler
2. Core Logic
SessionService.refresh() — src/auth/session.ts:147
- Validates refresh token against Redis + DB
- Enforces single-use rotation by default
- Issues new access token (15m) + refresh token (7d)
- Blacklists previous refresh token
3. Key Dependencies & Relationships
• RefreshTokenRepository (src/db/repositories/refresh-token.ts:18)
• RedisClient (src/infra/redis.ts)
• TokenBlacklistRepository
• UserRepository (lastLoginAt updates)
• JwtService.signAccessToken()
Call graph depth: 4 levels | 17 direct files | 41 indirect files
4. Impact Analysis
Changing refresh strategy affects:
- 14 backend files
- 3 background jobs
- Mobile SDKs (iOS + Android)
- Web frontend auth service
5. Security Recommendations
• Enforce refresh token rotation on every use
• Add device fingerprinting to refresh requests
• Implement refresh token family invalidation
• Add rate limiting + progressive backoff on refresh endpoint
• Improve audit logging for all token events
Analysis complete. Ready for detailed plan.
$
Cursor / Claude Code
You:
"Make the login flow more secure"
Agent:
Let me understand your request first...
mcp [ctxe ask_context]
"Where are all the files and logic related to the current login flow?"
The login flow involves src/api/auth/login.ts, src/middleware/jwt.ts, src/auth/session.ts, and several supporting services.
mcp [ctxe ask_context]
"What are the security-sensitive parts and current weaknesses in the authentication system?"
Current implementation lacks token rotation and has weak rate limiting around refresh endpoints.
Agent:
Now I understand the full scope of the login system and where the security gaps are.
Agent:
I can create a precise, safe plan. Ready to proceed?