What coldstart changes,
inside the session

Below is a walkthrough of one agent answering the same question twice on the same example repo, three days apart. The commands and the output format are the real ones.

Monday · nobody has written this down

It has to go and find out.

acme-apiClaude Code

how does authentication work in this codebase?

Nothing written down about auth here. I'll locate the files first.

OUT

Bash coldstart find auth session login middleware

find: auth session login middleware (4 terms, 112 candidate files)

▸ src/auth/session.ts [4/4]

Role: defines `session`, `login`; imports `auth`

Read: createSession [L24-58], verifySession [L62-91]

Wired: used by `requireAuth.ts`, `login.ts` · near `User.ts`

near L31:

L29: const token = randomBytes(32).toString('hex');

L31: await redis.set('sess:' + token, ..., 'EX', SESSION_TTL);

▸ src/middleware/requireAuth.ts [3/4]

Role: defines `middleware`, `auth`

Wired: uses `session.ts` · used by 14 route files

▸ src/routes/login.ts [3/4]

Role: defines `login`; imports `session`, `auth`

… +21 lines

OUT

Bash coldstart gs src/auth/session.ts

src/auth/session.ts (108 lines, importedBy: 6)

Symbols:

constant SESSION_TTL [L14]

constant COOKIE_NAME [L16]

function createSession [L24-58] ← src/routes/login.ts:41

function verifySession [L62-91] ← src/middleware/requireAuth.ts:18

function destroySession [L95-108] ← src/routes/logout.ts:12

Imports:

src/db/redis.ts

src/models/User.ts

Importers (6):

Source (4):

src/middleware/requireAuth.ts

src/routes/login.ts

src/routes/logout.ts

src/routes/refresh.ts

Tests (2):

tests/auth.test.ts

Edited together (git history, not a dependency):

src/middleware/requireAuth.ts — 14 commits

tests/auth.test.ts — 11 commits

Sessions, not JWTs — despite the variable being called token.

Login: src/routes/login.ts:41 checks the password, then calls createSession, which writes a random 32-byte token to Redis under sess:<token> with a 7-day TTL and returns it as an httpOnly cookie.

Every protected route: requireAuth pulls that cookie and calls verifySession, which is a single Redis lookup. Nothing is signed and nothing is decoded — if the key is gone from Redis, the session is over.

Logout: destroySession deletes the key. There is no revocation list because there is nothing to revoke.

Stop hook the agent writes this down — the files, the symbols, and the thing that would mislead the next reader — checked against a content hash so it expires when the code moves.

Reply to Claude…↑

Thursday · a different session, a different person

It starts at the right file.

acme-apiClaude Code

are we using JWTs for login, or something else?

From the notebookfresh

Auth is session cookies in Redis, not JWTs

createSession writes a random 32-byte token to Redis under sess:<token> with a 7-day TTL and returns an httpOnly cookie. requireAuth calls verifySession, a single Redis lookup, on every protected route. Nothing is signed or decoded. The variable is named token, which reads as a JWT and is not one — check Redis before assuming stateless auth.

src/auth/session.ts · createSession, verifySession

fresh = session.ts has not changed a byte since this was written.

The note names the file and the two functions. Opening it to confirm before I answer.

OUT

Read src/auth/session.ts

14 const SESSION_TTL = 60 * 60 * 24 * 7;

16 const COOKIE_NAME = 'sid';

24 export async function createSession(user: User) {

29 const token = randomBytes(32).toString('hex');

31 await redis.set('sess:' + token, JSON.stringify({ uid: user.id }),

32 'EX', SESSION_TTL);

35 return { name: COOKIE_NAME, value: token, httpOnly: true };

36 }

… +72 lines

Confirmed — not JWTs. Session cookies backed by Redis.

Login stores a random 32-byte token under sess:<token> with a 7-day TTL and sets it as an httpOnly cookie. requireAuth does one Redis lookup per request; nothing is signed or decoded. The token naming is misleading and has caught people out before.

Practically: sessions can be killed server-side by deleting the key, and auth stops working if Redis is down.

One read instead of a search. It still opened the file — it just knew which one, and it inherited the warning about the variable name.

Reply to Claude…↑

Both sessions had the index. Only the second had the note.

Neither is free. What changes is how much of the work goes into finding the file rather than answering the question.

Read the docs →How the notebook works