Memory System (Memories and Chronicle): Letting Codex Remember You Across Sessions

📚 Series Navigation: The previous article [18 Comprehensive Guide to config.toml Configurations] explained that row of behavior knobs at once—models, sandboxes, and approvals are all in one file. This article discusses something more fundamental: how to let Codex remember you across sessions. This includes not only the rules you manually write into AGENTS.md, but also the "private notes" it accumulates while working—correcting it once causes it to quietly record it in the background, recalling it automatically next time it starts work. Further along, we will also discuss Chronicle, an experimental Codex-exclusive feature that feeds memory using screen content.

Let's start with a real conversation snippet between my colleague and me.

Colleague: "Isn't your Codex memory enabled? I just told it 'use pnpm for this project from now on', but how come it turned around and did npm install again?" Me: "Did you expect it to remember immediately after you said it?" Colleague: "Yeah, the interface didn't report any errors." Me: "Memory isn't written in real-time. It waits until the session has been idle for a while to summarize in the background. If you test it right after saying it, of course it hasn't remembered yet. Besides, strict rules like 'must take effect every time' should be written in AGENTS.md in the first place, don't gamble on memory."

This conversation hides the two most common misunderstandings beginners have about Codex memory: first, assuming memory "takes effect immediately after speaking," and second, assuming memory can replace AGENTS.md. Neither is true, and both will trip you up at critical moments. This article untangles the Codex memory system from the ground up—when it records, where it stores, how to manage it, and what tasks should never be handed over to it.

By reading this article, you will get:

• A clear breakdown of the two memory systems in Codex: the AGENTS.md you write vs. the Memories it writes itself, summarized in a table
• Whether Memories is enabled by default, which regions cannot use it, how to enable it, which directory it is stored in, and why it is not updated in real-time
• How to control "whether to use memory and whether to generate memory for this session" per-session using /memories, along with the knobs you actually use in config.toml
• A "what to remember vs. what not to remember" checklist, plus a red line you must never cross
• Chronicle—an experimental Codex-exclusive capability that feeds memory using screen content: what it does, its hard restrictions (Pro + macOS only, excluding EU/UK/Switzerland), and the three privacy warnings officially stated
• A hands-on workflow you can follow to enable and verify that memory actually works

ℹ️ Compare this with the memory mechanism of Claude Code: over there, "auto-memory" is enabled by default, separated by git repositories, reading the first 200 lines or 25KB (whichever comes first) of MEMORY.md at start; the Codex system is different—it is disabled by default, has regional restrictions, runs asynchronous generation in the background, and has a different storage path and control interface. I will highlight these differences.

---

01 Distinguish First: Two Memory Systems, Not One

The bottom line: Codex manages two separate systems related to "remembering things"—one you write manually (AGENTS.md), and one it writes itself (Memories). When people mention "letting Codex remember," they only think of Memories, which is actually only half of the picture, and often the less reliable half.

Analogy: A team's 'tactic board' vs. 'scouting notes'. The coach writes clearly on the tactic board before the game—how to position, who marks whom, how to run set pieces—and the whole team must follow it. This is AGENTS.md: set by you, written in black and white, and re-read at the start of every game (every session). The other system is the notepad the scout scribbles on while sitting in the stands—"this opponent's left-side defense is soft," "that forward tends to cut inside." No one asked him to write this down; he accumulated it himself while watching, and flips it open next time they face the same opponent. This is Memories. Both are useful, but one is "I command you to do this," while the other is "rules of thumb I discovered myself."

The official docs define the roles of these two systems clearly, summarized in a comparison table—this is the first table you should memorize in this article:

Dimension	AGENTS.md	Memories
Written by	You (manually)	Codex (automatically generated)
Contents	Instructions and rules that must take effect every time	Stable context learned from past sessions
Typical Content	Build / test commands, code conventions, restricted zones	Your tech stack, project conventions, repeated workflows, pitfalls avoided
Default Switch	Always active (read when placed in repository)	Disabled by default, must be enabled manually
Reliability	Deterministic—read at every start	Probabilistic—background asynchronous generation, not guaranteed to be remembered
Committed to Git	Yes, shared across the team	No, local to machine, generated state files

See the key difference? AGENTS.md is "how you want it to work every time," while Memories is "contexts it discovered itself from the past to save you from repeating instructions." The official documentation sets the tone, which you must master first:

Keep team rules that must always take effect in AGENTS.md or version-controlled documents. Treat memory as a useful local recall layer, not the sole source for rules that must always be enforced.

In plain terms: Memories is the icing on the cake, not the safety net. My colleague's pnpm pitfall is a prime example—if you gamble on it remembering a strict rule like "only use pnpm for dependencies" in Memories, you will eventually fail (it might not have recorded it yet, it might not be injected in this session, or it might get squeezed out during merging). The correct approach is writing it into AGENTS.md, which is read deterministically at every start. 11 Project Instruction Manual AGENTS.md explained how to write AGENTS.md in detail; this article focuses on the other half—the notes it writes itself.

Let's map out these two memory paths, which eventually merge into the "new session context":

On the left is the deterministic path you write and place in the repository, AGENTS.md, read at every session start. On the right is Memories, which Codex accumulates in ~/.codex/memories/ while working, generated asynchronously in the background (disabled by default). The dotted line at the bottom represents Chronicle—optionally feeding Memories using your screen content (detailed in Section 05). Both solid paths merge into the "new session context," letting it "remember you" as soon as it starts work.

💡 Summary in one sentence: Codex has two memory systems—AGENTS.md is written by you, deterministic, read at every start, and committed to Git for the team; Memories is generated by it, probabilistic, disabled by default, and local to the machine; write rules that must always take effect in AGENTS.md, and do not rely on Memories to cover them.

---

02 Memories: The Notes It Writes Itself—How to Enable, Where Stored, How Processed

Here is the highlight—Memories, the notes Codex writes for itself while working. It solves a very real pain point: you don't want to explain "I use TypeScript, don't write semicolons, and run tests this way" from scratch every time you open a new session. With Memories enabled, it can carry these stable preferences, conventions, tech stacks, and pitfalls avoided over to subsequent tasks.

Analogy: Tacit understanding built with a long-term partner. You have to repeatedly teach a new intern, but a partner of three years understands you with a single look—because he remembers your habits and doesn't need constant reminders. Memories turns Codex from a "new intern" into a "long-term partner": you work and correct it normally, and it builds understanding silently behind the scenes for your next sessions.

Enable It First (Disabled by Default)

This is one of the biggest differences between Codex and Claude Code, highlighted separately:

Memories is disabled by default, and is unavailable in the European Economic Area (EEA), the United Kingdom, and Switzerland at release. Enable it in Codex settings, or write memories = true in the [features] table of ~/.codex/config.toml.

Choose one of two ways to enable:

Method 1: Enable via configuration file (written to ~/.codex/config.toml for long-term effect):

[features]
memories = true

Method 2: Enable Memories in Codex App settings (via the graphical user interface).

⚠️ Regional restrictions are enforced at the feature level by region, not due to network connectivity issues—if you are physically in the EEA / UK / Switzerland, you might not be able to enable it even with a VPN. This is the same geographic red line as Chronicle below; OpenAI drew boundaries for both features.

How It Actually Writes—Key Point: Background Asynchronous, Not Real-time

This is the cure for the conversation at the beginning, and the most counter-intuitive aspect of Codex memory. The official documentation states three clear mechanisms:

First, it distills from "eligible past sessions," not every single one. Once enabled, Codex converts useful past sessions into local memory files. However, it skips sessions that are still in progress or are too short-lived, avoiding summarizing unfinished work.

Second, it updates in the background and waits until you are "idle long enough." The official text: memory is not updated immediately after a session ends. Codex waits until the session has been idle for a sufficient duration to confirm you are not still working, before summarizing in the background. This is why my colleague's attempt to test it right after talking failed: the session was still warm, and it hadn't written memory yet.

Third, it skips runs when quotas are tight. If your remaining Codex rate-limit percentage falls below a configured threshold, background memory generation is skipped—preventing it from using up your remaining quota just to take notes.

A security design: when generating memories, Codex redacts credentials (like keys) inside memory fields. But note—this is "it trying to help you clean up," not "you can safely throw keys in," as detailed in the red line section.

Where It Is Stored

The official storage location is hardcoded, local to the machine:

Here is the conceptual structure; actual filenames are automatically generated by Codex:

~/.codex/memories/
├── (summary file)
├── (persistent entries file)
├── (recent input file)
└── (past session evidence file)

Key points:

It resides under your Codex home directory. The default is ~/.codex. If you set the CODEX_HOME environment variable elsewhere, it follows it. Main memory files are in ~/.codex/memories/, containing summaries, persistent entries, recent inputs, and evidence from past sessions.

Treat them as "generated states." The official docs instruct: these files are states generated by Codex. You can read them when troubleshooting or before sharing your Codex home directory, but do not treat 'manually editing these files' as your primary way of controlling them—use the /memories command and config options in the next section to manage memory behaviors, and avoid editing these files directly. This is another difference from Claude Code: over there, you are encouraged to read/write/delete files directly via /memory; here, Codex prefers you manage switches and policies while letting it generate the files.

Let's compare the "switches / storage / reliability" of the two memory paths side-by-side:

	AGENTS.md	Memories
Default State	Always read	Disabled by default, opt-in
Writing Timing	Takes effect when saved	Asynchronous background generation when idle
Storage	In repository, committed to Git	~/.codex/memories/, local, not in Git
Management	Direct file edits	Use /memories and config keys, avoid editing files directly

💡 Summary in one sentence: Memories are local notes automatically generated by Codex—disabled by default (enable with memories = true or in settings) and stored in ~/.codex/memories/; they are not written in real-time, waiting for sessions to be idle before summarizing in the background, and skipped when quotas are low; keys are redacted but don't treat it as a safety net; treat files as generated states and manage them via switches and configurations.

---

03 /memories and the Control Knobs: Managing When to Remember and Use

With Memories enabled, the next question is—do you want to use existing memories in this session? Do you want this session to generate new memories? For example, if you are debugging one-off experimental code, you don't want it to learn from it; or if you are working on a sensitive task, you don't want it to inject any old memories. Codex provides two layers of control: the session-level /memories command, and global configuration options.

Analogy: Separate 'record' and 'play' buttons on a voice recorder. "Play" is "whether to listen to past recordings" (using existing memories), while "record" is "whether to write this session down" (generating memories from this session). The two buttons are independent—you can listen without recording (using old memories but not learning from this run), record without listening, or turn both off. /memories is the control panel of this recorder.

Session-level: /memories

Type /memories in the Codex App or Codex TUI (Terminal User Interface) to manage only the current session:

/memories

Typing it prompts options—whether to use existing memories in this session, whether to use this session to generate future memories, or to disable memory behaviors entirely for this session. The official docs clarify: session-level choices do not change your global settings, affecting only the active session. New sessions will still follow your global configuration.

This is a highly practical design. My habit is: let it remember normally for 'standard project work', and use /memories to turn off memory generation as soon as I enter 'one-off dirty tasks / experiments / sensitive operations'—preventing it from cluttering the long-term notes with temporary garbage or sensitive contexts.

Global-level: config.toml Knobs

To define rules globally for the long term, write them under the [memories] table of ~/.codex/config.toml. Here are the ones you will actually use:

⚠️ Default values are subject to the official Config Reference and may change with versions; confirm against the documentation before applying.

Config Option	Role	Default Value
memories.use_memories	Set false to prevent injecting existing memories into new sessions	true
memories.generate_memories	Set false to prevent using new sessions as input for generating memories	true
memories.disable_on_external_context	Set true to exclude sessions using external context (like MCP / web search / tool search) from memory generation	false
memories.min_rate_limit_remaining_percent	Percentage threshold below which background memory generation is skipped	25
memories.extract_model	Overrides the model used for session-level memory extraction	Uses default if unset
memories.consolidation_model	Overrides the model used for global memory consolidation	Uses default if unset

For example, a common setup—letting it use old memories, but stopping it from learning new ones (when your memories are already set and you don't want them changing):

[memories]
generate_memories = false
use_memories = true

ℹ️ memories.disable_on_external_context has a legacy alias memories.no_memories_if_mcp_or_web_search. The official docs state the legacy name is still accepted—if you see it in old configs, don't worry, it's the same option. Once you connect MCP in Article 20 Connecting External Tools via MCP, you will understand this switch better: session contexts using external tools are not always clean, so blocking them from memory generation is a safe default.

💡 Summary in one sentence: Session-level control uses /memories to decide whether to use/generate memories for this run (without changing globals); global controls are defined under [memories] in config.toml—use_memories / generate_memories are the main switches, disable_on_external_context blocks sessions using external tools (default off), and min_rate_limit_remaining_percent defaults to 25.

---

04 What to Remember vs. What Not to Remember: A Hard Red Line

Having covered the mechanisms, let's look at the practical decisions—what is suitable for Memories, and what should never touch it. The good news is Memories is naturally conservative (focusing only on "stable, reusable" contexts, skipping short sessions); but you must know where the boundaries lie, especially the red line.

Comparing "suitable vs. unsuitable" items shows its primary domain:

❌ What NOT to let it remember (use AGENTS.md / temporary / sensitive)	✅ Its Primary Domain (stable / reusable / self-learning)
"Only use pnpm for dependencies, disable npm" (must take effect every time → write to AGENTS.md)	Your common tech stack (TypeScript + PostgreSQL + pytest)
"Use port 8081 for this run" (temporary, will mislead in two days)	Repeated workflows (running lint before opening PRs)
"I am debugging the login page now" (temporary state)	Project conventions (this repo's tests require starting a local server first)
Database passwords / API keys / tokens (sensitive! Red line!)	Pitfalls avoided (the root cause of that flaky bug was missing timezone settings)

Three rules of thumb for judgment:

First: "Does it need to take effect every time?" This is the first check in Codex. If a rule must always take effect, write it in AGENTS.md and do not gamble on Memories. Memories is probabilistic—it might not have generated yet, it might not be injected, or it might get squeezed out. My colleague's pnpm issue was essentially handing a mandatory rule over to a probabilistic system.

Second: "Will it change / is it reusable?" One-off, soon-to-change, "for now" settings are not suitable (ports, temp variables, debugging states); things you will use next time and the time after (tech stacks, conventions, pitfalls avoided) are what it should accumulate.

Third: "Is it sensitive?"—this is the red line, bolded three times:

Do not store credentials in memories. Codex redacts generated memory fields, but you should still inspect memory files before sharing your Codex home directory or generated memory assets.

Note the nuance in this warning: "it redacts" does not mean "you can throw things in." Memories are stored as unencrypted, plain-text Markdown on your hard drive. Redaction is a safety net, not a permission. Therefore—passwords, tokens, and API keys must never enter memory files, aligning with general security practices where sensitive data does not enter code, commits, or logs. Additionally, a habit for Codex: before sharing ~/.codex or exporting memories, inspect ~/.codex/memories/ to make sure no sensitive information leaks.

💡 Summary in one sentence: Follow the three checks—rules that must always take effect go to AGENTS.md instead of memories; changing / temporary states are skipped; credentials must never enter memories (stored as plain text, redaction is only a fallback); scan memories/ before sharing ~/.codex. Memories excel at "stable, reusable, self-learned" contexts.

---

05 Chronicle: Feeding Memory by Letting Codex "Watch the Screen" (Experimental)

This section covers a Codex-exclusive capability—Chronicle. Claude Code does not have a counterpart.

⚠️ Experimental, subject to change. Chronicle is an "opt-in research preview." Any entry points, menu names, and default behaviors mentioned below are subject to what you see on your screen and the official Codex documentation. Subsequent versions may adjust these.

What It Is and What It Does

In short: standard Memories learn from your "dialogue" with Codex; Chronicle goes further, learning from "content on your screen." It feeds recent screen context to memories, helping Codex understand what you are pointing to, which source to use, and what tools/workflows you depend on.

Analogy: An assistant who can glance at your monitor. A standard assistant only hears what you say; the Chronicle assistant can glance at your screen—"ah, you are looking at this error," "you just modified this PR"—so you don't have to explain it from scratch. The official docs list three benefits: using what you are currently looking at (saving context-switching explanations), completing partial contexts (no need to construct background from scratch), and remembering your tools and workflows (learning over time how you use tools for tasks).

A key detail: Chronicle doesn't always digest screen content itself, but rather uses it as "clues." The docs state that when a more suitable source exists (a file, Slack thread, Google Doc, dashboard, or PR), Chronicle uses screen context to identify that source, then accesses it directly.

Hard Restrictions: Region + Platform

Let's address the restrictions first, as they decide whether you can use it at all:

Chronicle is only available for ChatGPT Pro subscribers, on macOS, and is not yet available in the EU, the United Kingdom, or Switzerland.

Three gates, all required:

• Subscription: Must be ChatGPT Pro (standard Plus is not enough).
• Platform: macOS only (no Windows or Linux—the Codex desktop App itself lacks a Linux version, as covered in 07 Desktop App).
• Region: EU, UK, and Switzerland are not supported (matching the region restrictions of Memories).

It also requires two macOS system permissions: Screen Recording and Accessibility—to see your screen and interact with the system. Setup path: Codex App settings → Personalization → confirm Memories is enabled → enable Chronicle below → click Continue on the consent prompt → grant the two permissions.

Three Privacy Warnings: Understand Before Enabling

This is critical. The official docs highlight the risks right at the beginning. Do not skip these three warnings:

1. Consumes quotas quickly. Chronicle runs sandbox agents in the background to generate memories from screenshots, and these agents currently consume rate limits rapidly. Enabling it will drop your quota faster than usual.
2. Increases prompt injection risk. Using Chronicle increases the risk of prompt injection attacks from screen content—for example, if you browse a website hiding malicious agent instructions, Codex might follow those instructions. This is the same issue covered in 16 Security and Risk Boundaries, but with a wider attack surface since it reads screen content you do not control.
3. Memories are stored unencrypted locally. Memories generated by Chronicle are stored as unencrypted Markdown files on your computer, matching other Codex memories.

Balance these warnings against the convenience. My stance matches 02 Core Concepts: feel free to try it, but pause it when viewing sensitive screen content (passwords, private chats, client data, meeting feeds). To pause it, click the Codex icon in the menu bar and select Pause Chronicle (click Resume Chronicle to turn it back on). The docs instruct: pause it before meetings and before viewing sensitive content; also, a strict rule—do not use Chronicle to record meetings or communications with others without their consent (it does not capture microphone or system audio, but screenshots will capture images).

Data Storage: Is It Shared with OpenAI?

The details you need to know:

• Screenshots are temporary: Stored briefly on your computer, appearing under $TMPDIR/chronicle/screen_recording/ during execution, and automatically deleted after 6 hours.
• Generated memories are local: Saved under $CODEX_HOME/memories_extensions/chronicle/ (usually ~/.codex/memories_extensions/chronicle/) as Markdown files you can read and edit. To make it forget something, delete the file or edit the Markdown to remove that section; but the docs warn: do not manually add new information to it.
• How screenshots are processed: To generate memories, Chronicle starts a temporary Codex session, which may process selected screenshot frames, OCR text, timestamps, and related local file paths. Screenshots are discarded after processing on OpenAI servers—they are not retained (unless required by law) and are not used for training.

💡 Summary in one sentence: Chronicle is a Codex-exclusive experimental feature feeding memory using screen content, restricted to Pro + macOS, excluding EU/UK/Switzerland, requiring screen recording + accessibility permissions; note three warnings—fast quota consumption, high prompt injection risk, and plain-text local storage; use Pause Chronicle before sensitive content; screenshots are temporary (deleted in 6 hours), memories are in ~/.codex/memories_extensions/chronicle/, and server processing is discard-only with no training.

Let's illustrate these two memory systems:

This diagram compares the two memory systems: on the left, Memories learns from your dialogues, stores in ~/.codex/memories/, and is disabled by default (enable with memories = true). On the right, Chronicle learns from screen content, stores in ~/.codex/memories_extensions/chronicle/, and is a Pro + macOS exclusive experimental capability. Both merge into the "new session context" to remember you from start.

---

06 Hands-on: Enable Memories, Record a Preference, and Verify

Practice makes perfect. Below is a minimal workflow: enable Memories → feed a stable preference in a session → verify the file is generated → control behavior with /memories. It does not rely on complex environments.

Platform differences: Run mkdir commands in macOS / Linux directly; run in Git Bash or WSL on Windows. The path ~ refers to the user home directory (C:\Users\username\ on Windows). Also—Memories cannot be enabled if you are in the EEA / UK / Switzerland; if this step is unavailable, it is region-restricted, not a bug.

Step 1: Enable Memories

Edit ~/.codex/config.toml and add (create the file if it does not exist):

[features]
memories = true

Expected: Save the file. Alternatively, enable Memories in Codex App settings.

Step 2: Create a dummy project and start Codex

mkdir memory-demo
cd memory-demo
codex

Expected: Enter the Codex session interface.

Step 3: Feed a stable preference in the session

Perform some tasks and explicitly state a preference worth remembering long-term. For example:

From now on, use pytest to run tests for this project, and run them before committing. Remember this habit.

Expected: Codex responds and follows. Note that this preference will not enter memory files immediately. Recall Section 02: memory is generated asynchronously in the background. It waits until the session has been idle for a sufficient duration (the default min_rollout_idle_hours is 6 hours) to confirm you are done, before summarizing. Do not expect to see it in the file in your next message—feel this behavior firsthand, which was the issue my colleague faced.

Step 4: Use /memories to control session behavior

To verify something immediately, use session-level controls. Type in the session:

/memories

Expected: Prompts choices to use existing memories, generate memories, or disable memory behaviors entirely for this session. Choose to disable generation. The docs state this affects only the active session, leaving globals intact. This step is immediate and shows feedback on the spot, unlike background generation.

Step 5: Check if memory files are generated after some time

Memory generation is asynchronous, so check back later (letting the session cool down). Inspect the storage directory:

ls ~/.codex/memories/

Expected: Memory files generated by Codex (summaries, persistent entries, etc.) appear. Seeing files means Memories is accumulating contexts. To read them, open the Markdown files directly (plain text)—but remember: these are generated states, do not edit them manually as your main control method. Use /memories and config.toml to manage them.

⚠️ If ~/.codex/memories/ remains empty after a long time, check: ① is memories = true active in [features]? ② are you in the EEA / UK / Switzerland? (if so, it is unavailable) ③ was the session too short to be summarized? (short sessions are skipped) ④ is your remaining quota below the threshold? (defaults to 25%, below which generation is skipped). These checks cover most issues.

Running this sequence lets you verify the memory path: enable memory → feed context → understand why it is not immediate → control session with /memories → check disk files later.

---

07 Summary

We have untangled the Codex memory systems—clarifying that they are two separate systems, and that Codex's memories differ significantly from Claude Code's.

Let's review the key points:

Objective	Conclusion
How many memory systems?	Two systems: AGENTS.md for manual rules (deterministic) + Memories for automated notes (probabilistic)
Is Memories on by default?	Disabled by default, enable with memories = true or in settings; not available in EEA / UK / Switzerland
How is it written?	Asynchronous background generation when idle; skipped if quotas are low; credentials are redacted (only a fallback)
Where is it stored?	~/.codex/memories/, local to machine, not in Git; treat as "generated states"
How to manage it?	Session-level /memories (no global change) + global controls under [memories] in config.toml
What to remember vs skip	Mandatory rules go to AGENTS.md; temporary/changing states are skipped; credentials must never enter
What is Chronicle?	Experimental, screen-fed memory; Pro + macOS only, excluding EU/UK/Switzerland; note three warnings: fast quota use, prompt injection risk, plain-text local files

You should now be able to: distinguish between AGENTS.md and Memories and understand why mandatory rules go to the former; enable Memories, know why it is not real-time, and locate its files; control session behaviors with /memories and configurations; decide what information to feed it and avoid credentials; and understand the Chronicle experimental capability and its privacy costs. Simply put—you can guide Codex to remember what it should and avoid what it shouldn't, rather than gambling mandatory rules on a probabilistic system.

Memory is about letting Codex "remember past contexts." To connect it to the external world beyond your local machine, we use a different protocol.

💡 Summary in one sentence: Two memory paths—AGENTS.md for deterministic safety and Memories for probabilistic assistance—managed using /memories and config.toml switches; Chronicle is a Pro + macOS exclusive screen-fed memory experimental feature, which should be paused before viewing sensitive content.

---

The next article [20 Connecting External Tools via MCP]—memory makes Codex "understand you better," while MCP (Model Context Protocol) lets it "reach further": connecting databases, APIs, and third-party services that it cannot reach locally through a unified protocol. You will then fully understand what the disable_on_external_context switch from Section 03 defends against. A quick thought: both "give Codex information it doesn't know"—when should you "let it remember a preference" vs. "connect an external tool to search in real-time"?

---

Recommended Reading

• Writing Prompts: Speaking to Codex's Strengths
• Comprehensive Guide: Adding Features and Committing a dummy TODO Tool
• Command Line CLI Guide