Prompt file imported from SpreadZhao/codex-ecc (.codex/prompts/ecc-save-session.md). Copyright stays with the author.

ECC Command Prompt: /save-session

Name: ecc-save-session
Author: SpreadZhao

Source: /nix/store/7bmy0z0ymx3hgjbhiiixxi0f43djs56c-source/commands/save-session.md

Use this prompt to run the ECC save-session workflow in Codex.

Save Session Command

Capture everything that happened in this session — what was built, what worked, what failed, what's left — and write it to a dated file so the next session can pick up exactly where this one left off.

When to Use

End of a work session before closing Claude Code
Before hitting context limits (run this first, then start a fresh session)
After solving a complex problem you want to remember
Any time you need to hand off context to a future session

Process

Step 1: Gather context

Before writing the file, collect:

Read all files modified during this session (use git diff or recall from conversation)
Review what was discussed, attempted, and decided
Note any errors encountered and how they were resolved (or not)
Check current test/build status if relevant

Step 2: Create the sessions folder if it doesn't exist

Create the canonical sessions folder in the user's Claude home directory:

mkdir -p ~/.claude/session-data

Step 3: Write the session file

Create ~/.claude/session-data/YYYY-MM-DD-<short-id>-session.tmp, using today's actual date and a short-id that satisfies the rules enforced by SESSION_FILENAME_REGEX in session-manager.js:

Compatibility characters: letters a-z / A-Z, digits 0-9, hyphens -, underscores _
Compatibility minimum length: 1 character
Recommended style for new files: lowercase letters, digits, and hyphens with 8+ characters to avoid collisions

Valid examples: abc123de, a1b2c3d4, frontend-worktree-1, ChezMoi_2 Avoid for new files: A, test_id1, ABC123de

Full valid filename example: 2024-01-15-abc123de-session.tmp

The legacy filename YYYY-MM-DD-session.tmp is still valid, but new session files should prefer the short-id form to avoid same-day collisions.

Step 4: Populate the file with all sections below

Write every section honestly. Do not skip sections — write "Nothing yet" or "N/A" if a section genuinely has no content. An incomplete file is worse than an honest empty section.

Step 5: Show the file to the user

After writing, display the full contents and ask:

Session saved to [actual resolved path to the session file]

Does this look accurate? Anything to correct or add before we close?

Wait for confirmation. Make edits if requested.

Session File Format

# Session: YYYY-MM-DD

**Started:** [approximate time if known]
**Last Updated:** [current time]
**Project:** [project name or path]
**Topic:** [one-line summary of what this session was about]

---

## What We Are Building

[1-3 paragraphs describing the feature, bug fix, or task. Include enough
context that someone with zero memory of this session can understand the goal.
Include: what it does, why it's needed, how it fits into the larger system.]

---

## What WORKED (with evidence)

[List only things that are confirmed working. For each item include WHY you
know it works — test passed, ran in browser, Postman returned 200, etc.
Without evidence, move it to "Not Tried Yet" instead.]

- **[thing that works]** — confirmed by: [specific evidence]
- **[thing that works]** — confirmed by: [specific evidence]

If nothing is confirmed working yet: "Nothing confirmed working yet — all approaches still in progress or untested."

---

## What Did NOT Work (and why)

[This is the most important section. List every approach tried that failed.
For each failure write the EXACT reason so the next session doesn't retry it.
Be specific: "threw X error because Y" is useful. "didn't work" is not.]

- **[approach tried]** — failed because: [exact reason / error message]
- **[approach tried]** — failed because: [exact reason / error message]

If nothing failed: "No failed approaches yet."

---

## What Has NOT Been Tried Yet

[Approaches that seem promising but haven't been attempted. Ideas from the
conversation. Alternative solutions worth exploring. Be specific enough that
the next session knows exactly what to try.]

- [approach / idea]
- [approach / idea]

If nothing is queued: "No specific untried approaches identified."

---

## Current State of Files

[Every file touched this session. Be precise about what state each file is in.]

| File              | Status         | Notes                      |
| ----------------- | -------------- | -------------------------- |
| `path/to/file.ts` | PASS: Complete    | [what it does]             |
| `path/to/file.ts` |  In Progress | [what's done, what's left] |
| `path/to/file.ts` | FAIL: Broken      | [what's wrong]             |
| `path/to/file.ts` |  Not Started | [planned but not touched]  |

If no files were touched: "No files modified this session."

---

## Decisions Made

[Architecture choices, tradeoffs accepted, approaches chosen and why.
These prevent the next session from relitigating settled decisions.]

- **[decision]** — reason: [why this was chosen over alternatives]

If no significant decisions: "No major decisions made this session."

---

## Blockers & Open Questions

[Anything unresolved that the next session needs to address or investigate.
Questions that came up but weren't answered. External dependencies waiting on.]

- [blocker / open question]

If none: "No active blockers."

---

## Exact Next Step

[If known: The single most important thing to do when resuming. Be precise
enough that resuming requires zero thinking about where to start.]

[If not known: "Next step not determined — review 'What Has NOT Been Tried Yet'
and 'Blockers' sections to decide on direction before starting."]

---

## Environment & Setup Notes

[Only fill this if relevant — commands needed to run the project, env vars
required, services that need to be running, etc. Skip if standard setup.]

[If none: omit this section entirely.]

Example Output

# Session: 2024-01-15

**Started:** ~2pm
**Last Updated:** 5:30pm
**Project:** my-app
**Topic:** Building JWT authentication with httpOnly cookies

---

## What We Are Building

User authentication system for the Next.js app. Users register with email/password,
receive a JWT stored in an httpOnly cookie (not localStorage), and protected routes
check for a valid token via middleware. The goal is session persistence across browser
refreshes without exposing the token to JavaScript.

---

## What WORKED (with evidence)

- **`/api/auth/register` endpoint** — confirmed by: Postman POST returns 200 with user
  object, row visible in Supabase dashboard, bcrypt hash stored correctly
- **JWT generation in `lib/auth.ts`** — confirmed by: unit test passes
  (`npm test -- auth.test.ts`), decoded token at jwt.io shows correct payload
- **Password hashing** — confirmed by: `bcrypt.compare()` returns true in test

---

## What Did NOT Work (and why)

- **Next-Auth library** — failed because: conflicts with our custom Prisma adapter,
  threw "Cannot use adapter with credentials provider in this configuration" on every
  request. Not worth debugging — too opinionated for our setup.
- **Storing JWT in localStorage** — failed because: SSR renders happen before
  localStorage is available, caused React hydration mismatch error on every page load.
  This approach is fundamentally incompatible with Next.js SSR.

---

## What Has NOT Been Tried Yet

- Store JWT as httpOnly cookie in the login route response (most likely solution)
- Use `cookies()` from `next/headers` to read token in server components
- Write middleware.ts to protect routes by checking cookie existence

---

## Current State of Files

| File                             | Status         | Notes                                           |
| -------------------------------- | -------------- | ----------------------------------------------- |
| `app/api/auth/register/route.ts` | PASS: Complete    | Works, tested                                   |
| `app/api/auth/login/route.ts`    |  In Progress | Token generates but not setting cookie yet      |
| `lib/auth.ts`                    | PASS: Complete    | JWT helpers, all tested                         |
| `middleware.ts`                  |  Not Started | Route protection, needs cookie read logic first |
| `app/login/page.tsx`             |  Not Started | UI not started                                  |

---

## Decisions Made

- **httpOnly cookie over localStorage** — reason: prevents XSS token theft, works with SSR
- **Custom auth over Next-Auth** — reason: Next-Auth conflicts with our Prisma setup, not worth the fight

---

## Blockers & Open Questions

- Does `cookies().set()` work inside a Route Handler or only in Server Actions? Need to verify.

---

## Exact Next Step

In `app/api/auth/login/route.ts`, after generating the JWT, set it as an httpOnly
cookie using `cookies().set('token', jwt, { httpOnly: true, secure: true, sameSite: 'strict' })`.
Then test with Postman — the response should include a `Set-Cookie` header.

Notes

Each session gets its own file — never append to a previous session's file
The "What Did NOT Work" section is the most critical — future sessions will blindly retry failed approaches without it
If the user asks to save mid-session (not just at the end), save what's known so far and mark in-progress items clearly
The file is meant to be read by Claude at the start of the next session via /resume-session
Use the canonical global session store: ~/.claude/session-data/
Prefer the short-id filename form (YYYY-MM-DD-<short-id>-session.tmp) for any new session file

# ECC Command Prompt: /save-session Source: /nix/store/7bmy0z0ymx3hgjbhiiixxi0f43djs56c-source/commands/save-session.md Use this prompt to run the ECC `save-session` workflow in Codex. # Save Session Command Capture everything that happened in this session — what was built, what worked, what failed, what's left — and write it to a dated file so the next session can pick up exactly where this one left off. ## When to Use - End of a work session before closing Claude Code - Before hitting context limits (run this first, then start a fresh session) - After solving a complex problem you want to remember - Any time you need to hand off context to a future session ## Process ### Step 1: Gather context Before writing the file, collect: - Read all files modified during this session (use git diff or recall from conversation) - Review what was discussed, attempted, and decided - Note any errors encountered and how they were resolved (or not) - Check current test/build status if relevant ### Step 2: Create the sessions folder if it doesn't exist Create the canonical sessions folder in the user's Claude home directory: ```bash mkdir -p ~/.claude/session-data ``` ### Step 3: Write the session file Create `~/.claude/session-data/YYYY-MM-DD-<short-id>-session.tmp`, using today's actual date and a short-id that satisfies the rules enforced by `SESSION_FILENAME_REGEX` in `session-manager.js`: - Compatibility characters: letters `a-z` / `A-Z`, digits `0-9`, hyphens `-`, underscores `_` - Compatibility minimum length: 1 character - Recommended style for new files: lowercase letters, digits, and hyphens with 8+ characters to avoid collisions Valid examples: `abc123de`, `a1b2c3d4`, `frontend-worktree-1`, `ChezMoi_2` Avoid for new files: `A`, `test_id1`, `ABC123de` Full valid filename example: `2024-01-15-abc123de-session.tmp` The legacy filename `YYYY-MM-DD-session.tmp` is still valid, but new session files should prefer the short-id form to avoid same-day collisions. ### Step 4: Populate the file with all sections below Write every section honestly. Do not skip sections — write "Nothing yet" or "N/A" if a section genuinely has no content. An incomplete file is worse than an honest empty section. ### Step 5: Show the file to the user After writing, display the full contents and ask: ``` Session saved to [actual resolved path to the session file] Does this look accurate? Anything to correct or add before we close? ``` Wait for confirmation. Make edits if requested. --- ## Session File Format ```markdown # Session: YYYY-MM-DD **Started:** [approximate time if known] **Last Updated:** [current time] **Project:** [project name or path] **Topic:** [one-line summary of what this session was about] --- ## What We Are Building [1-3 paragraphs describing the feature, bug fix, or task. Include enough context that someone with zero memory of this session can understand the goal. Include: what it does, why it's needed, how it fits into the larger system.] --- ## What WORKED (with evidence) [List only things that are confirmed working. For each item include WHY you know it works — test passed, ran in browser, Postman returned 200, etc. Without evidence, move it to "Not Tried Yet" instead.] - **[thing that works]** — confirmed by: [specific evidence] - **[thing that works]** — confirmed by: [specific evidence] If nothing is confirmed working yet: "Nothing confirmed working yet — all approaches still in progress or untested." --- ## What Did NOT Work (and why) [This is the most important section. List every approach tried that failed. For each failure write the EXACT reason so the next session doesn't retry it. Be specific: "threw X error because Y" is useful. "didn't work" is not.] - **[approach tried]** — failed because: [exact reason / error message] - **[approach tried]** — failed because: [exact reason / error message] If nothing failed: "No failed approaches yet." --- ## What Has NOT Been Tried Yet [Approaches that seem promising but haven't been attempted. Ideas from the conversation. Alternative solutions worth exploring. Be specific enough that the next session knows exactly what to try.] - [approach / idea] - [approach / idea] If nothing is queued: "No specific untried approaches identified." --- ## Current State of Files [Every file touched this session. Be precise about what state each file is in.] | File | Status | Notes | | ----------------- | -------------- | -------------------------- | | `path/to/file.ts` | PASS: Complete | [what it does] | | `path/to/file.ts` | In Progress | [what's done, what's left] | | `path/to/file.ts` | FAIL: Broken | [what's wrong] | | `path/to/file.ts` | Not Started | [planned but not touched] | If no files were touched: "No files modified this session." --- ## Decisions Made [Architecture choices, tradeoffs accepted, approaches chosen and why. These prevent the next session from relitigating settled decisions.] - **[decision]** — reason: [why this was chosen over alternatives] If no significant decisions: "No major decisions made this session." --- ## Blockers & Open Questions [Anything unresolved that the next session needs to address or investigate. Questions that came up but weren't answered. External dependencies waiting on.] - [blocker / open question] If none: "No active blockers." --- ## Exact Next Step [If known: The single most important thing to do when resuming. Be precise enough that resuming requires zero thinking about where to start.] [If not known: "Next step not determined — review 'What Has NOT Been Tried Yet' and 'Blockers' sections to decide on direction before starting."] --- ## Environment & Setup Notes [Only fill this if relevant — commands needed to run the project, env vars required, services that need to be running, etc. Skip if standard setup.] [If none: omit this section entirely.] ``` --- ## Example Output ```markdown # Session: 2024-01-15 **Started:** ~2pm **Last Updated:** 5:30pm **Project:** my-app **Topic:** Building JWT authentication with httpOnly cookies --- ## What We Are Building User authentication system for the Next.js app. Users register with email/password, receive a JWT stored in an httpOnly cookie (not localStorage), and protected routes check for a valid token via middleware. The goal is session persistence across browser refreshes without exposing the token to JavaScript. --- ## What WORKED (with evidence) - **`/api/auth/register` endpoint** — confirmed by: Postman POST returns 200 with user object, row visible in Supabase dashboard, bcrypt hash stored correctly - **JWT generation in `lib/auth.ts`** — confirmed by: unit test passes (`npm test -- auth.test.ts`), decoded token at jwt.io shows correct payload - **Password hashing** — confirmed by: `bcrypt.compare()` returns true in test --- ## What Did NOT Work (and why) - **Next-Auth library** — failed because: conflicts with our custom Prisma adapter, threw "Cannot use adapter with credentials provider in this configuration" on every request. Not worth debugging — too opinionated for our setup. - **Storing JWT in localStorage** — failed because: SSR renders happen before localStorage is available, caused React hydration mismatch error on every page load. This approach is fundamentally incompatible with Next.js SSR. --- ## What Has NOT Been Tried Yet - Store JWT as httpOnly cookie in the login route response (most likely solution) - Use `cookies()` from `next/headers` to read token in server components - Write middleware.ts to protect routes by checking cookie existence --- ## Current State of Files | File | Status | Notes | | -------------------------------- | -------------- | ----------------------------------------------- | | `app/api/auth/register/route.ts` | PASS: Complete | Works, tested | | `app/api/auth/login/route.ts` | In Progress | Token generates but not setting cookie yet | | `lib/auth.ts` | PASS: Complete | JWT helpers, all tested | | `middleware.ts` | Not Started | Route protection, needs cookie read logic first | | `app/login/page.tsx` | Not Started | UI not started | --- ## Decisions Made - **httpOnly cookie over localStorage** — reason: prevents XSS token theft, works with SSR - **Custom auth over Next-Auth** — reason: Next-Auth conflicts with our Prisma setup, not worth the fight --- ## Blockers & Open Questions - Does `cookies().set()` work inside a Route Handler or only in Server Actions? Need to verify. --- ## Exact Next Step In `app/api/auth/login/route.ts`, after generating the JWT, set it as an httpOnly cookie using `cookies().set('token', jwt, { httpOnly: true, secure: true, sameSite: 'strict' })`. Then test with Postman — the response should include a `Set-Cookie` header. ``` --- ## Notes - Each session gets its own file — never append to a previous session's file - The "What Did NOT Work" section is the most critical — future sessions will blindly retry failed approaches without it - If the user asks to save mid-session (not just at the end), save what's known so far and mark in-progress items clearly - The file is meant to be read by Claude at the start of the next session via `/resume-session` - Use the canonical global session store: `~/.claude/session-data/` - Prefer the short-id filename form (`YYYY-MM-DD-<short-id>-session.tmp`) for any new session file

{ "prompt": "# ECC Command Prompt: /save-session\n\nSource: /nix/store/7bmy0z0ymx3hgjbhiiixxi0f43djs56c-source/commands/save-session.md\n\nUse this prompt to run the ECC `save-session` workflow in Codex.\n\n\n# Save Session Command\n\nCapture everything that happened in this session — what was built, what worked, what failed, what's left — and write it to a dated file so the next session can pick up exactly where this one left off.\n\n## When to Use\n\n- End of a work session before closing Claude Code\n- Before hitting context limits (run this first, then start a fresh session)\n- After solving a complex problem you want to remember\n- Any time you need to hand off context to a future session\n\n## Process\n\n### Step 1: Gather context\n\nBefore writing the file, collect:\n\n- Read all files modified during this session (use git diff or recall from conversation)\n- Review what was discussed, attempted, and decided\n- Note any errors encountered and how they were resolved (or not)\n- Check current test/build status if relevant\n\n### Step 2: Create the sessions folder if it doesn't exist\n\nCreate the canonical sessions folder in the user's Claude home directory:\n\n```bash\nmkdir -p ~/.claude/session-data\n```\n\n### Step 3: Write the session file\n\nCreate `~/.claude/session-data/YYYY-MM-DD-<short-id>-session.tmp`, using today's actual date and a short-id that satisfies the rules enforced by `SESSION_FILENAME_REGEX` in `session-manager.js`:\n\n- Compatibility characters: letters `a-z` / `A-Z`, digits `0-9`, hyphens `-`, underscores `_`\n- Compatibility minimum length: 1 character\n- Recommended style for new files: lowercase letters, digits, and hyphens with 8+ characters to avoid collisions\n\nValid examples: `abc123de`, `a1b2c3d4`, `frontend-worktree-1`, `ChezMoi_2`\nAvoid for new files: `A`, `test_id1`, `ABC123de`\n\nFull valid filename example: `2024-01-15-abc123de-session.tmp`\n\nThe legacy filename `YYYY-MM-DD-session.tmp` is still valid, but new session files should prefer the short-id form to avoid same-day collisions.\n\n### Step 4: Populate the file with all sections below\n\nWrite every section honestly. Do not skip sections — write \"Nothing yet\" or \"N/A\" if a section genuinely has no content. An incomplete file is worse than an honest empty section.\n\n### Step 5: Show the file to the user\n\nAfter writing, display the full contents and ask:\n\n```\nSession saved to [actual resolved path to the session file]\n\nDoes this look accurate? Anything to correct or add before we close?\n```\n\nWait for confirmation. Make edits if requested.\n\n---\n\n## Session File Format\n\n```markdown\n# Session: YYYY-MM-DD\n\n**Started:** [approximate time if known]\n**Last Updated:** [current time]\n**Project:** [project name or path]\n**Topic:** [one-line summary of what this session was about]\n\n---\n\n## What We Are Building\n\n[1-3 paragraphs describing the feature, bug fix, or task. Include enough\ncontext that someone with zero memory of this session can understand the goal.\nInclude: what it does, why it's needed, how it fits into the larger system.]\n\n---\n\n## What WORKED (with evidence)\n\n[List only things that are confirmed working. For each item include WHY you\nknow it works — test passed, ran in browser, Postman returned 200, etc.\nWithout evidence, move it to \"Not Tried Yet\" instead.]\n\n- **[thing that works]** — confirmed by: [specific evidence]\n- **[thing that works]** — confirmed by: [specific evidence]\n\nIf nothing is confirmed working yet: \"Nothing confirmed working yet — all approaches still in progress or untested.\"\n\n---\n\n## What Did NOT Work (and why)\n\n[This is the most important section. List every approach tried that failed.\nFor each failure write the EXACT reason so the next session doesn't retry it.\nBe specific: \"threw X error because Y\" is useful. \"didn't work\" is not.]\n\n- **[approach tried]** — failed because: [exact reason / error message]\n- **[approach tried]** — failed because: [exact reason / error message]\n\nIf nothing failed: \"No failed approaches yet.\"\n\n---\n\n## What Has NOT Been Tried Yet\n\n[Approaches that seem promising but haven't been attempted. Ideas from the\nconversation. Alternative solutions worth exploring. Be specific enough that\nthe next session knows exactly what to try.]\n\n- [approach / idea]\n- [approach / idea]\n\nIf nothing is queued: \"No specific untried approaches identified.\"\n\n---\n\n## Current State of Files\n\n[Every file touched this session. Be precise about what state each file is in.]\n\n| File | Status | Notes |\n| ----------------- | -------------- | -------------------------- |\n| `path/to/file.ts` | PASS: Complete | [what it does] |\n| `path/to/file.ts` | In Progress | [what's done, what's left] |\n| `path/to/file.ts` | FAIL: Broken | [what's wrong] |\n| `path/to/file.ts` | Not Started | [planned but not touched] |\n\nIf no files were touched: \"No files modified this session.\"\n\n---\n\n## Decisions Made\n\n[Architecture choices, tradeoffs accepted, approaches chosen and why.\nThese prevent the next session from relitigating settled decisions.]\n\n- **[decision]** — reason: [why this was chosen over alternatives]\n\nIf no significant decisions: \"No major decisions made this session.\"\n\n---\n\n## Blockers & Open Questions\n\n[Anything unresolved that the next session needs to address or investigate.\nQuestions that came up but weren't answered. External dependencies waiting on.]\n\n- [blocker / open question]\n\nIf none: \"No active blockers.\"\n\n---\n\n## Exact Next Step\n\n[If known: The single most important thing to do when resuming. Be precise\nenough that resuming requires zero thinking about where to start.]\n\n[If not known: \"Next step not determined — review 'What Has NOT Been Tried Yet'\nand 'Blockers' sections to decide on direction before starting.\"]\n\n---\n\n## Environment & Setup Notes\n\n[Only fill this if relevant — commands needed to run the project, env vars\nrequired, services that need to be running, etc. Skip if standard setup.]\n\n[If none: omit this section entirely.]\n```\n\n---\n\n## Example Output\n\n```markdown\n# Session: 2024-01-15\n\n**Started:** ~2pm\n**Last Updated:** 5:30pm\n**Project:** my-app\n**Topic:** Building JWT authentication with httpOnly cookies\n\n---\n\n## What We Are Building\n\nUser authentication system for the Next.js app. Users register with email/password,\nreceive a JWT stored in an httpOnly cookie (not localStorage), and protected routes\ncheck for a valid token via middleware. The goal is session persistence across browser\nrefreshes without exposing the token to JavaScript.\n\n---\n\n## What WORKED (with evidence)\n\n- **`/api/auth/register` endpoint** — confirmed by: Postman POST returns 200 with user\n object, row visible in Supabase dashboard, bcrypt hash stored correctly\n- **JWT generation in `lib/auth.ts`** — confirmed by: unit test passes\n (`npm test -- auth.test.ts`), decoded token at jwt.io shows correct payload\n- **Password hashing** — confirmed by: `bcrypt.compare()` returns true in test\n\n---\n\n## What Did NOT Work (and why)\n\n- **Next-Auth library** — failed because: conflicts with our custom Prisma adapter,\n threw \"Cannot use adapter with credentials provider in this configuration\" on every\n request. Not worth debugging — too opinionated for our setup.\n- **Storing JWT in localStorage** — failed because: SSR renders happen before\n localStorage is available, caused React hydration mismatch error on every page load.\n This approach is fundamentally incompatible with Next.js SSR.\n\n---\n\n## What Has NOT Been Tried Yet\n\n- Store JWT as httpOnly cookie in the login route response (most likely solution)\n- Use `cookies()` from `next/headers` to read token in server components\n- Write middleware.ts to protect routes by checking cookie existence\n\n---\n\n## Current State of Files\n\n| File | Status | Notes |\n| -------------------------------- | -------------- | ----------------------------------------------- |\n| `app/api/auth/register/route.ts` | PASS: Complete | Works, tested |\n| `app/api/auth/login/route.ts` | In Progress | Token generates but not setting cookie yet |\n| `lib/auth.ts` | PASS: Complete | JWT helpers, all tested |\n| `middleware.ts` | Not Started | Route protection, needs cookie read logic first |\n| `app/login/page.tsx` | Not Started | UI not started |\n\n---\n\n## Decisions Made\n\n- **httpOnly cookie over localStorage** — reason: prevents XSS token theft, works with SSR\n- **Custom auth over Next-Auth** — reason: Next-Auth conflicts with our Prisma setup, not worth the fight\n\n---\n\n## Blockers & Open Questions\n\n- Does `cookies().set()` work inside a Route Handler or only in Server Actions? Need to verify.\n\n---\n\n## Exact Next Step\n\nIn `app/api/auth/login/route.ts`, after generating the JWT, set it as an httpOnly\ncookie using `cookies().set('token', jwt, { httpOnly: true, secure: true, sameSite: 'strict' })`.\nThen test with Postman — the response should include a `Set-Cookie` header.\n```\n\n---\n\n## Notes\n\n- Each session gets its own file — never append to a previous session's file\n- The \"What Did NOT Work\" section is the most critical — future sessions will blindly retry failed approaches without it\n- If the user asks to save mid-session (not just at the end), save what's known so far and mark in-progress items clearly\n- The file is meant to be read by Claude at the start of the next session via `/resume-session`\n- Use the canonical global session store: `~/.claude/session-data/`\n- Prefer the short-id filename form (`YYYY-MM-DD-<short-id>-session.tmp`) for any new session file", "variables": [], "notes": "Source: /nix/store/7bmy0z0ymx3hgjbhiiixxi0f43djs56c-source/commands/save-session.md", "metadata": { "source": { "provider": "github-codex-prompts", "repository": "https://github.com/SpreadZhao/codex-ecc", "path": ".codex/prompts/ecc-save-session.md", "ref": "42e5e807d9f32faeb4bd991bf7c77e050a917126", "url": "https://github.com/SpreadZhao/codex-ecc/blob/42e5e807d9f32faeb4bd991bf7c77e050a917126/.codex/prompts/ecc-save-session.md", "key": "SpreadZhao/codex-ecc/.codex/prompts/ecc-save-session.md" } } }

ecc-save-session

About