Amazon Q Developer is AWS's AI coding assistant. It evolved from CodeWhisperer, expanding from inline completions to a full conversational agent that can explain code, generate implementations, transform code between frameworks, and scan for security vulnerabilities. It's available in VS Code, JetBrains IDEs, and the AWS Console, with deep integration into the AWS ecosystem — IAM policy generation, CloudFormation troubleshooting, resource configuration, and billing analysis.

But Q Developer has a gap. Every conversation starts from zero. It doesn't know what you built last sprint, what architectural trade-offs shaped the current design, or why you chose that particular DynamoDB partition key strategy after three days of load testing. You explain. You move on. You explain again next session.

That's not a flaw in Q Developer. It's the underlying architecture. And there's a practical way to extend it.

What Q Developer resets every time

The context loss is easy to underestimate until it compounds. Here's what disappears at the end of each session:

Project decisions. Why you chose DynamoDB over Aurora for this service. Why you ruled out Lambda@Edge in favor of CloudFront Functions. What trade-offs shaped the current CDK stack structure.
Coding conventions. How you structure Lambda handlers in this project. The error handling patterns your team uses across API Gateway integrations. The IAM policy conventions that aren't documented anywhere.
Debugging history. That investigation into the 502 errors from API Gateway last Thursday. The root cause you eventually traced to a Lambda response format mismatch. The fix and why it holds.
Accumulated context. Everything you re-established in the last conversation that you'll need to re-establish again tomorrow.

Q Developer does have access to your open files and workspace in the IDE. That's helpful for immediate code context. But workspace awareness is not memory. It can see what your code looks like right now — not the decisions that shaped it, the alternatives you rejected, or the debugging sessions that refined it.

Why this is a hard problem for Q Developer to solve alone

Q Developer is built on large language models. LLMs process a context window and produce output — but they don't write to persistent storage between calls. When the conversation ends, the context window closes and what was in it is gone.

This is a property of how these models work, not something AWS can simply configure away. Every coding agent on the market has the same constraint — GitHub Copilot, Cursor, Claude Code, all of them. The reset is universal because the cause is universal.

For a deeper look at why this is architecturally hard to solve, see How AI coding assistants forget everything.

What customizations can do (and what they can't)

Q Developer supports customizations — you can point it at your internal code repositories and documentation so it generates code that matches your organization's patterns. For enterprise teams on AWS, this is a meaningful feature. It means Q Developer's suggestions align with your internal libraries and frameworks rather than generic open-source patterns.

But customizations are static references. They reflect what your code looks like, not why it looks that way. They can't hold the reasoning behind a decision made under pressure, or the three CDK deployment strategies you evaluated before settling on the current one, or what you were debugging when you stopped work on Friday. Customizations improve code generation accuracy. They don't give Q Developer memory.

Adding persistent memory to Q Developer

Amazon Q Developer does not currently support Model Context Protocol (MCP). That means the direct MCP integration path — where the coding agent connects to a MemNexus MCP server and reads/writes memory autonomously — isn't available yet for Q Developer itself.

There are two practical approaches that work today.

Approach 1: MemNexus CLI alongside Q Developer

The MemNexus CLI (mx) gives you direct access to your memory store from the terminal. You search for context before starting a Q Developer conversation, and you save important decisions after.

Setup

npm install -g @memnexus-ai/mx-agent-cli

# Interactive prompt — key stays out of shell history
mx auth login

mx setup

Workflow: pull context before a Q Developer session

Before starting a conversation with Q Developer, search your memory store for relevant context:

# Find what you know about this area of the project
mx memories search --query "API Gateway error handling patterns"

# Get a structured briefing before starting work
mx memories build-context --context "refactoring the order service Lambda handlers"

# Recall everything about a specific decision
mx memories recall --query "why we chose DynamoDB single-table design"

Copy the relevant context into your Q Developer conversation. The agent now has the background it needs — without you typing it from memory.

# Quick copy to clipboard (macOS)
mx memories search --query "Lambda cold start optimizations" | pbcopy

# On Linux
mx memories search --query "Lambda cold start optimizations" | xclip -selection clipboard

Workflow: save decisions after a Q Developer session

When Q Developer helps you reach an important decision or resolve a tricky bug, save it:

# Save a decision
mx memories create --content "Chose API Gateway REST over HTTP API for the payment service because we need request validation, WAF integration, and usage plans. HTTP API is cheaper but doesn't support these features." --product myproject --service payment-api

# Save a debugging finding
mx memories create --content "API Gateway 502s on the order endpoint were caused by Lambda returning a string body instead of JSON. The fix: always JSON.stringify the response body and set Content-Type header explicitly. This affects all Lambda proxy integrations." --product myproject --service order-api

# Save a convention
mx memories create --content "All Lambda handlers in this project use the shared error-handler middleware from layers/common. Never catch errors directly in the handler — let the middleware format the API Gateway response." --product myproject --service core

These memories persist across sessions, across projects, and across tools. The next time you or any coding agent connected to your MemNexus account encounters a similar problem, the context is there.

Approach 2: MCP via your IDE

If you use Q Developer in VS Code or JetBrains — IDEs that support MCP — you can run the MemNexus MCP server alongside Q Developer. The MCP server is available to any MCP-compatible tool in the same IDE. While Q Developer won't call the MCP tools directly, other agents in your workflow (Copilot, Claude Code, Continue.dev) can read and write the same memory store. Your context accumulates regardless of which tool you're using at any given moment.

# mx setup detects your IDE and configures the MCP server
mx setup

This means your Q Developer sessions feed into the same memory store that your other coding agents draw from. A decision you save after a Q Developer conversation is available to Claude Code, Copilot, or any MCP-connected tool in the next session.

What actually persists across sessions

Here's what MemNexus stores and surfaces across your Q Developer sessions:

AWS conventions with context. Not just "we use CDK" but how you structure CDK stacks in this project, why you use a specific Lambda layer pattern, and the IAM policy boundary your team enforces. Details that customizations can reference but can't explain.

Decisions with their reasoning. "We use DynamoDB" is table stakes. "We chose DynamoDB single-table design after benchmarking Aurora Serverless cold starts at 800ms versus DynamoDB consistent reads at 4ms, and the access patterns in the order service are pure key-value with no cross-entity joins" is what a coding agent actually needs to give relevant suggestions.

Debugging history. That investigation into Lambda timeout errors you completed last week — root cause, fix, what you ruled out along the way — becomes a memory. When similar symptoms appear in your next Q Developer session, you can pull that context in seconds instead of re-investigating.

Cross-tool continuity. If you use Q Developer for AWS-specific work and another coding agent for general development, both draw from the same memory store. Context doesn't fragment across tools.

The compound effect

The value isn't obvious on day one. It compounds.

After a few weeks, you walk into each Q Developer session with the actual history of your project available in a quick CLI search — not just the customizations you configured at the start, but the decisions you made under pressure, the bugs you traced to their root, the patterns that emerged from real use. Re-explanation drops. Discovery time drops. The things you've already figured out stay figured out.

The right tool for each job: Q Developer's deep AWS integration, security scanning, and code transformation capabilities are hard to replicate. MemNexus adds the one thing Q Developer can't provide alone — memory that outlasts the session.

Using a different AI coding tool?

The same approach works across the coding agent ecosystem — and for tools with MCP support, the integration is even more seamless:

GitHub Copilot Memory: How to Make Copilot Remember Your Project — persistent context for Copilot Chat
How to Give Claude Code Persistent Memory Across Projects — persistent memory for Claude Code
Kiro Memory: How to Make Kiro Remember Your Project — persistent memory for Kiro (AWS's agentic IDE)
How to Give Cursor Persistent Memory Across Sessions — adding persistent memory to Cursor
OpenAI Codex Memory: How to Make Codex Remember Your Codebase — persistent memory for OpenAI Codex
How to Give Windsurf Persistent Memory Across Sessions — adding persistent memory to Cascade
Continue.dev Memory: How to Make Continue Remember Your Project — persistent memory for Continue.dev

MemNexus is currently in invite-only preview. If you want Amazon Q Developer to actually remember your project, request access at memnexus.ai/waitlist.

For setup documentation and CLI reference, see the MemNexus docs.

Amazon Q Developer Memory: How to Make Q Developer Remember Your Project