# Connect Codex to Rakuten Shared Memory

For Rakuten account managers using Codex on Windows. Connect it once on your work computer, then ask it to find account information, save agreed updates and help keep that information current. You do not need to code or hand-edit settings.

The [illustrated user guide](https://memory.rmgops.com/guide) shows the screens and explains the features. The [current onboarding handout](https://memory.rmgops.com/setup/codex) is available for future downloads.

Service owner and setup help: **Rich Masters — [richard.masters@rakuten.com](mailto:richard.masters@rakuten.com)**. For access to a particular account's information, contact that scope's owner; Codex can help you find them.

Three words you will see:

- A **scope** is a collection of information about a subject, such as an account or product. Its membership decides who can read the working records.
- A **record** is one short fact, with its author, date and source.
- **Signing in** connects Codex to Shared Memory as you, through your browser. There is no key to copy or save.

Shared Memory lets Codex find and save information in the personal and shared scopes your Rakuten account can access. The basic connection does not bulk-upload your existing chats, local files or local Codex memories. Sending information to a memory tool is a separate action.

**Never paste a sign-in link into a Codex chat or send it to an AI assistant.** You sign in yourself, in your own browser. Codex never needs to see a sign-in link, a password or a token.

## Before you start

You need Codex installed and working, your `@rakuten.com` email address, and access to that inbox. Use your own Windows account on your own approved work device. Set this up separately for each Windows user and computer; administrator access is not needed.

These commands are for a local Windows installation. If you use a Mac, Linux, Windows Subsystem for Linux (WSL), or a remote Codex computer, ask Rich for the appropriate setup before running them. If your organisation blocks configuration changes, contact Rich or your IT team. Do not change security settings to get around a restriction.

Follow steps 1 to 5 in order. Each user signs in as themselves on their own machine; nothing is shared between people. The optional hooks and IT rollout notes are separate from the standard setup.

## Start here: let Codex walk you through it

Give this file from the channel to your Codex chat and simply say:

> help me onboard this with you and codex

That is all you need to ask. You do not need a special prompt, technical terminology or an understanding of the code. The instructions for Codex are inside this file: it should read them, check what is already set up, give you one action at a time, and help you learn the account tasks after the connection works. You will still sign in yourself, in your browser, outside the chat.

You can tell Codex where you are up to, such as `connection added` or `signed in`. If you get stuck, say `I'm stuck at step [number]; I see [message]`. Replace the square-bracketed words with your own details, but never send a sign-in link.

If you cannot attach the file, give Codex the [onboarding link](https://memory.rmgops.com/setup/codex) and ask it to read the handout before helping you. If it cannot open the link, paste the handout's text, not any credentials.

Already connected? Tell Codex: `Check my Shared Memory connection without saving anything. If it works, help me learn the account tasks in this guide. Do not change my connection or reinstall anything.`

## 1. Sign in to Shared Memory

1. Open [memory.rmgops.com/login.html](https://memory.rmgops.com/login.html).
2. Enter your Rakuten email address and select **Send sign-in link**.
3. Open the email in your own inbox and select the sign-in link.

The link works once and expires after 15 minutes. If it expires, request another. This service currently uses email sign-in, not Okta. Do not forward the link or paste it into an AI chat.

Doing this first means step 3 goes straight to the **Allow** page. If you skip it, step 3 asks you to sign in on the way.

See the [illustrated setup steps](https://memory.rmgops.com/guide#start).

## 2. Let Codex add the connection

Codex calls this connection an **MCP server**. You do not need to manage it yourself. If you used the request under "Start here", let Codex check or add the connection. It must preserve an existing working setup and must not add a duplicate entry.

### Recommended: ask Codex to configure it

If you are following the steps yourself rather than using guided setup, paste this request into Codex. It contains no credentials:

> Configure the Rakuten Shared Memory MCP for this Windows user. Use the endpoint https://memory.rmgops.com/mcp with no token: I will sign in through my browser. Back up the existing Codex config, preserve all other settings, and add or verify the shared-memory entry. Set default_tools_approval_mode to writes. Do not ask me to paste a sign-in link or token into chat, and do not sign in for me. Do not install hooks or change AGENTS.md. Check the configuration without creating or changing memory records. Tell me what remains to be done.

Codex can configure the connection without signing in as you. It may ask you to approve a local configuration change. Review the destination and change before approving.

### Manual alternative

Skip this alternative if Codex is doing the setup for you. Open the Windows **Start** menu, type `PowerShell`, and open **Windows PowerShell**. Do not select **Run as administrator**. Run:

```powershell
codex mcp add shared-memory --url https://memory.rmgops.com/mcp
```

In the Codex desktop app or the VS Code extension, you can instead open the MCP servers settings, add a **Streamable HTTP** server named `shared-memory` with the URL `https://memory.rmgops.com/mcp`, and save it.

To also set the approval mode below, edit the configuration file. Use this only if you are comfortable editing configuration files. The default file is `%USERPROFILE%\.codex\config.toml`. If your installation uses a custom `CODEX_HOME`, ask Rich which file to edit. Close Codex, make a backup copy of `config.toml`, then open the original in a text editor. Preserve the existing contents. The `shared-memory` entry should read:

```toml
[mcp_servers.shared-memory]
url = "https://memory.rmgops.com/mcp"
default_tools_approval_mode = "writes"
```

Save the file as `config.toml`, not `config.toml.txt`. There is no token in this entry: Codex keeps its sign-in separately.

The `writes` setting requests approval for tools that are not marked read-only. The look-up tools (`recall`, `session_brief`, `list_scopes`, `find_scopes`, `review_scope`, `list_facets`, `list_groups`) are marked read-only, so this setting does not request a prompt for them. Tools that save, change or delete memory (`write`, `edit`, `delete_record`, `create_scope`, `update_scope`, `delete_scope`, `flag_conflict`) request approval. Your installed client, other approval settings and organisation's policy must support and honour that behaviour; Rich should verify it before rollout. Codex should also explain a proposed change and wait for your agreement, not rely only on a technical approval prompt.

## 3. Sign in from Codex

Do this yourself, not through the Codex chat. In **Windows PowerShell**, run:

```powershell
codex mcp login shared-memory
```

In the Codex desktop app or the VS Code extension, you can instead open the MCP servers settings and select **Authenticate** beside `shared-memory`.

Your browser opens the Shared Memory **Allow** page:

1. If it asks you to sign in, select **Sign in**, follow the email link in the new tab, then come back to the first tab. It continues on its own; if it does not, select **I've signed in**.
2. Check that the page says **Allow an app on this computer?**, names Codex, and shows your own email address. If it shows someone else's, select **Cancel**.
3. Select **Allow**. The browser shows a short page from Codex saying sign-in worked; you can close that tab.

The app name on that page is only what the app calls itself, so it is not the real check. The real check is that you started this sign-in from Codex yourself, just now. If the page appears when you did not, select **Cancel**.

Once you have selected **Allow**, tell Codex `signed in`.

Codex keeps itself signed in: it renews its access every hour without asking you. You sign in again only if you have not used it for 30 days, and at least once every 90 days. Each sign-in is listed in the web app under **Apps** (in the menu under your email, top right), **Connected apps**, where **Disconnect** cuts off that one app at once. See [connected apps](https://memory.rmgops.com/guide#tokens).

Set up with a token before? It keeps working; you do not have to switch. To switch, remove the `bearer_token_env_var` line from the `shared-memory` entry (or ask Codex to), then do steps 3 to 5. Once the new sign-in works, revoke the old token under **Apps**, **Advanced: tokens for scripts and services**, unless the optional hooks use it. Look for the name you gave it (for example `Codex - work laptop`). Entries named **magic-link login** are browser sign-ins, not the separately named Codex token.

## 4. Restart Codex completely

Save any open work first. Codex should tell you which restart applies to your setup:

- **Codex desktop app:** close every Codex window and quit the app completely, then reopen it.
- **Codex inside VS Code:** close every VS Code window and quit VS Code completely, then reopen it.
- **Codex in a terminal:** exit the Codex session, close its terminal, then open a new terminal and start Codex again.

Start a new chat and attach this same handout again. Use the resume request in step 5 so the new chat knows where you are up to. If you cannot attach it, include the [onboarding link](https://memory.rmgops.com/setup/codex) and ask Codex to read it first.

Adding the connection or signing in does not guarantee that an existing chat has loaded the new MCP tools.

## 5. Check the connection without writing anything

In a new Codex chat, send:

> I've restarted Codex. Please continue onboarding using this guide.

With the handout attached again, Codex should run the live, read-only connection check, help resolve any failure, then explain your scopes and everyday account tasks. You do not need to name the tools or repeat the setup instructions.

The connection is working when Codex confirms that the live `list_scopes` call succeeded. An entry in the config, the browser's sign-in message, or `codex mcp list` alone does not prove that the connection works. After the check, Codex should explain your available scopes and offer the everyday tasks below; you do not need to create a test record.

If you are new, `list_scopes` may show only **Your notes**, your private scope. That is normal. You see shared scopes once an owner adds you, or adds a group you belong to.

If the client does not expose the tool, use the troubleshooting section. Do not test the connection by creating a sample memory record.

If you cannot see an account's scope, ask Codex to find its owner so you can request access. Creating another scope or saving the account's information to **Your notes** is not a substitute for joining the right shared scope.

## Using Shared Memory after setup

You can use normal language. Replace the square-bracketed parts of these examples with your own details. Codex should explain what it found or proposes to do and include the relevant illustrated-guide link.

### Find account information

> Find the latest agreed terms and next steps for [account] in Shared Memory. Show the source and date, flag conflicting information and tell me what is missing. Do not save anything.

### Save an agreed update

> We agreed [update] for [account] on [date], in [meeting or document]. Check existing records first. Show me the correct scope, proposed text, source and classification before asking me to approve a save.

Save reusable decisions and facts, not an entire client file or every passing idea. If an update comes from a deck, email or meeting note, name that source. For these two tasks, see [using Shared Memory through Codex](https://memory.rmgops.com/guide#agent).

### Correct outdated information

> This information about [account] is outdated: [text]. Find the existing record and propose a correction using [new information and source]. Ask before editing. If I cannot change it, tell me who can help.

Authors can correct their own records; scope owners can correct any record in their scope. See [record actions](https://memory.rmgops.com/guide#records) and [change history](https://memory.rmgops.com/guide#history).

### Get access to an account's scope

> Help me find the scope for [account]. If I cannot access it, tell me which owner to contact and what to ask. Do not create a duplicate scope or save the account information to my private notes instead.

There is no join-request button. Contact the named owner and ask them to add your Rakuten email address. See [scope membership](https://memory.rmgops.com/guide#members).

### Check who will see an update

> Before saving [update], tell me who can see the proposed destination, including access through groups. Recommend an appropriate classification. If you cannot confirm the audience, show me where to check it in the web app. Do not save yet.

See [how access works](https://memory.rmgops.com/guide#basics), [members](https://memory.rmgops.com/guide#members) and [groups](https://memory.rmgops.com/guide#groups).

### Share access or publish a record

> Help me give [colleague's Rakuten email] access to [scope]. Explain whether I have permission, then show me the Members steps in the web app. If I am not an owner, tell me which owner to contact.

> Help me understand whether I can publish [record] company-wide. Explain who would then see it and guide me through the web app. Do not publish or change its classification for me.

Adding someone to a scope gives them access to its working records. Publishing makes a separate copy of a selected record available to everyone at Rakuten. These are different actions: check the intended audience and your permission to share before either. Codex can explain the steps, but membership changes and publishing are done by you in the web app. See [adding members](https://memory.rmgops.com/guide#members) and [publishing records](https://memory.rmgops.com/guide#records).

Check the destination scope before saving. Personal and shared scopes have different audiences. A shared scope can be visible to other members, including people who receive access through a group. Do not store tokens, passwords, sign-in links or information you are not authorised to share.

This guide connects Codex to Shared Memory. You can then ask it to find or save information. Automatic start-of-chat summaries and reminders are an optional addition arranged by Rich; you do not need them to use Shared Memory, and this guide does not install them. Connecting the MCP does not guarantee that Codex consults Shared Memory on every turn. This service is separate from Codex's local memory feature.

### Pause memory use in this chat

Send `#memory off` for no lookups or saving, `#memory read-only` for lookups only, or `#memory on` to return to normal. Codex is instructed to respect these modes. Optional managed hooks add technical enforcement; the basic connection alone does not enforce them. A new chat starts back at `on`. See [chat controls](https://memory.rmgops.com/guide#agent).

### Scopes: who can see what

- A **scope** is a subject, such as an account, a product or a project. Its members can read its working records; published copies are readable by everyone at Rakuten. **Your notes** is your private scope and cannot be shared or published.
- A scope can have **several owners**. Owners add people, promote members to owner, change settings and add groups. A scope always keeps at least one owner.
- Owners add people by pasting a list of `@rakuten.com` addresses into the scope's **Members** tab in the web app. Other domains are rejected.
- A **group** is a reusable list of people, such as a team. When a group is added to a scope, everyone in the group gets access, including people who join later.

### Where Codex saves things

The service asks Codex to check with you rather than guess:

1. If one of your scopes matches the subject, Codex uses it.
2. If none does, Codex searches every findable scope at Rakuten (`find_scopes`), including ones you are not in. Search shows a scope's name, owners and size, never its records. If a match exists, Codex tells you who owns it so you can ask to be added, rather than creating a duplicate.
3. If nothing matches, Codex proposes a new shared scope, with a name, its subject tags and who should be in it, and creates it only if you agree.
4. It uses **Your notes** only if you choose that or the information is personal to you, and it tells you that's where it went.

If Codex quietly saves to Your notes or skips saving without telling you, say so. That isn't the intended behaviour.

Before saving, Codex checks whether the fact is already recorded. If what it tries to save closely matches a record already in that scope, the service refuses it and shows the match. Codex should then offer to update the existing record instead. It saves a new record only if you agree the fact is genuinely different, and the reason it gives is logged.

Each record also keeps where it came from. Facts settled in the chat are recorded as coming from the conversation, along with which connection saved them. If a fact comes from something you shared, such as a document, deck, email, transcript or meeting notes, tell Codex (for example, "this is from the Q3 partner review deck") and it records that source, so others can tell a document's claim from something said in chat.

### What never to store

Never store: card and bank numbers, tax IDs, payment details, transaction-level client data, clients' customers' personal data (consumer emails, phone numbers, order-level data), credentials, and opinions or personal details about named people beyond their working role.

Client contacts: names and roles only where the fact needs them; contact details stay in Salesforce. Codex is told the same, and the service checks saves for card, bank, tax ID, phone and non-staff email patterns.

### Sealed scopes for confidential projects

For an NDA or otherwise confidential project, an owner can **seal** the scope, either in the web app (**Settings → Visibility**) or by asking Codex. A sealed scope never appears in search, so only its members know it exists, and its records cannot be published company-wide. Because sealed scopes are never listed, an empty search does not prove that a scope doesn't exist.

### Tidying scopes you own

Owners run their scope: they can fix, retag, relabel or delete **any** record in it, not just their own, and take down a record that was published company-wide. Every change is logged with whose record it was. Publishing a record company-wide is the author's or an owner's call, made in the web app; Codex can't publish, and other members can't publish someone else's record.

Ask your agent, for example:

> Let's tidy the scopes I own. Start with the ANZ publishers scope.

It reviews the scope and points out untagged records, tags stored in the wrong place, duplicates, contradictions, records nobody has used and old records. It works through them with you a batch at a time and changes only what you approve. An owner can also delete a whole team scope (for example a test or duplicate scope), from the web app's Settings tab or by asking Codex; Codex must confirm the exact scope name with you first, and everything in the scope, including published copies, is removed.

### Classification labels

Every record is labelled `public`, `internal`, `confidential` or `restricted`; the web app shows it on each record. A record without a label is treated as `internal`. Each scope has a **ceiling**, the most sensitive label it accepts, so confidential material can't land in a scope that isn't set up for it.

A label describes sensitivity, not who can read the record. Labelling a record `public` does not publish it or put it on the internet. Labelling it `confidential` does not hide it from other scope members. Everyone in a scope can read its working records, so check the audience before saving. Never lower a label just to make a save or sharing action succeed. See [labels and publishing](https://memory.rmgops.com/guide#records) and [classification ceilings](https://memory.rmgops.com/guide#settings).

### Subject tags (facets)

Records and scopes can be tagged with what they are about: `account`, `region`, `vertical`, `partner`, `partner-type`, `team` and `product`. Records inherit their scope's tags, so Codex can find everything about an account across every scope you can see.

`vertical` and `partner-type` are fixed lists taken from Salesforce. Codex maps common wording to the list (for example, fashion becomes `apparel-accessories` and cashback publishers become `loyalty-rewards`) and pushes back if you ask for a value that isn't on it. If a category is genuinely missing, ask Rich to arrange its addition.

### Asking where something came from

When Codex uses a record, it can tell you which scope it came from, who wrote it and when, and why you can see it: you're a member, you're in a group that was added, or the record was published company-wide. If something looks wrong or surprising, ask "where did that come from?" Codex can then correct its own record, flag a conflict between two records, or name the scope's owner so they can fix it.

## Troubleshooting

Say to Codex: `I'm stuck at step [number]; I see [non-secret error message]. Help me with one action at a time.` If you still need help, contact **Rich Masters — [richard.masters@rakuten.com](mailto:richard.masters@rakuten.com)**. For company-managed restrictions, involve your IT team; for access to an account scope, contact its owner. See the [illustrated questions and fixes](https://memory.rmgops.com/guide#faq).

### The sign-in email did not arrive

Check junk or spam and confirm that you entered your `@rakuten.com` address. Request another link if needed. The website's acknowledgement does not prove the email arrived. If this persists, contact Rich.

### Codex says it needs to sign in, or reports 401

Sign in again using step 3, then restart using step 4 and check again using step 5. This is expected after 30 days without use, after 90 days, or after you select **Disconnect** for Codex in the web app.

### The browser does not open, or Codex runs on another computer

Run `codex mcp login shared-memory --no-browser`. It prints a sign-in address: open it in your own browser, select **Allow**, and follow what Codex shows next. If Codex runs on a remote computer, ask Rich before continuing.

### The browser says "This sign-in can't continue"

Start again from step 3. If it keeps happening, update Codex and try again, then contact Rich with the message shown; it contains nothing secret. If `codex mcp login` says sign-in is not supported, update Codex.

### After a Shared Memory update, a tool refuses a value or says a field is missing

Codex is still using the old tool list. Fully restart the app or terminal that runs Codex, following step 4, and start a new chat.

### The server is configured but no tools appear

Fully restart the app or terminal that runs Codex, following step 4, and start a new chat. Ask Codex to check for a disabled server, a duplicate entry, a configuration error or an organisation policy restriction. The expected endpoint is `https://memory.rmgops.com/mcp`, not the sign-in page. If the service is unreachable, contact Rich.

### I pasted a sign-in link or token into chat by accident

A sign-in link stops working once it has been used and after 15 minutes; request a new one if you still need it. If it was a token, treat it as exposed: open **Apps**, then **Advanced: tokens for scripts and services**, find its name and select **Revoke**. The page should say **Revoked.** Entries named **magic-link login** are browser sign-ins, not the separately named Codex token. See [connected apps and tokens](https://memory.rmgops.com/guide#tokens). Remove the exposed copy where possible and follow your organisation's incident process. Deleting a message alone does not make a token safe to keep using. Contact Rich if you need help; do not email him the token.

### What can I send to support?

Send Rich the step you reached, the non-secret error message, and whether you use the Codex app, VS Code or a terminal. Include your Codex version if you can find it; ask Codex how to check it if you cannot. Remove credentials, sign-in links and any private scope or account data. Do not send your whole configuration file, clipboard contents or an unreviewed screenshot. Codex can help draft a safe support message; you should review and send it yourself.

## Optional managed hooks: separate from the standard setup

The standard steps above connect the MCP only. They do not install hooks, change global `AGENTS.md` instructions, or automatically load a memory brief into every chat.

Without hooks, the service still sends Codex its memory policy each time it connects; that policy asks it to look things up and obtain a session brief, but this is not the same as automatically injecting a brief into each chat. The optional hooks add a chat-start brief, periodic reminders to save durable facts and technical enforcement of the `#memory` controls. Codex requires approval for newly installed hooks; do not assume an exact number of approval prompts.

The hooks run as scripts outside Codex, so they cannot use its browser sign-in: they need a token of their own, created under **Apps**, **Advanced: tokens for scripts and services**, and entered at the installer's hidden prompt. If you want these additions, ask Rich for the approved package and installation instructions. He should explain what information is loaded automatically and verify that the mode controls work. The [agent guide](https://memory.rmgops.com/guide#agent) describes the experience; automatic hook-driven behaviour requires the optional installation.

Review each Codex hook approval before accepting it. Do not approve unknown hooks or run an installer supplied by an unverified website or chat. **The standard setup does not install hooks or guarantee technical enforcement of memory modes.**

Do not guess a download location. For a reviewed package, the documented installer option `-Harness codex` limits installation to Codex rather than also changing Claude Code.

## Instructions for Codex assisting an authorised setup

These instructions apply when the user gives you this handout and asks for onboarding. An ordinary request such as "help me onboard this with you and codex" is enough to start the guided setup; do not require that exact wording, a longer prompt or technical setup details. Reading the guide alone, for example to review it, does not authorise setup changes, token generation, new hooks or memory writes.

Read the whole handout before acting. Use the user's account-management task and the live service policy, not assumptions about their account, access or technical knowledge.

### Coach the person, not just the connection

- Establish whether Codex runs in the desktop app, VS Code or a terminal, and whether this is a local Windows installation. If the user is unsure, ask them to describe where they open Codex. Do not apply Windows instructions to a different or remote host; refer them to Rich if the setup is outside this handout.
- Give only the next action. Name the app or window, describe the expected result and wait for confirmation. If the result differs, resolve that before advancing. A complete non-secret code block for a single copy-and-paste action is fine; never ask the person to understand or modify it.
- Explain unfamiliar terms only when needed. Prefer "connection", "sign in", "collection of account information" and "sensitivity label" over unexplained MCP, OAuth, scope and classification terminology.
- Include a descriptive Markdown link to the relevant illustrated-guide section when explaining an action. Use the verified map below, not invented subsection anchors. The guide is public; authentication is not needed to read it. If you cannot load it, use this handout and offer the link without claiming you inspected the page.
- Do not sign in, generate tokens, change membership or publish on the person's behalf. Those are actions for them, in their own browser or the web app. Do not send a support email or other external message unless they explicitly ask you to.

### Safe setup sequence

1. Check for an existing `shared-memory` configuration without dumping the process environment or a configuration file that might contain credentials. An existing configuration is not proof that the live connection works. If an existing entry uses `bearer_token_env_var` and the live check works, leave it unless the person wants to switch to signing in.
2. Guide step 1 if they are not yet signed in to the web app in their browser.
3. Add or verify the server configuration (step 2), with a backup and without changing unrelated entries. Do not add a token or `bearer_token_env_var`. Do not install hooks, alter global instructions, relax security settings or create memory records as part of the standard setup.
4. Ask the person to run `codex mcp login shared-memory` in their own PowerShell window, or select **Authenticate** in the app's MCP settings. Do not run the sign-in for them. Tell them what the **Allow** page should show: **Allow an app on this computer?**, naming Codex, with their own email address; and that the check that matters is that they started this sign-in themselves just now. Pause for them to say `signed in`.
5. Do not ask for a sign-in link, the address the browser ends up on, clipboard access, a screenshot of the browser or any token. If they post one anyway, do not quote it, save it or use it; tell them a sign-in link expires by itself, and that a token must be revoked under **Apps**, **Advanced**.
6. Give the correct restart instructions for their Codex client and tell them to reattach this handout in a fresh chat. Supply the resume request from step 5 before they leave. Explain that the new tools may not be available in the current chat. In the fresh chat, make a read-only `list_scopes` call if the tool is available. If it fails with a sign-in or 401 error, guide step 3 again.
7. Report the actual state: `configuration prepared`, `signed in`, or `live connection verified`. Do not claim completion until the live read-only call succeeds. If sign-in or restart is still needed, say so explicitly.

### After verification: help them use it

Explain the scopes returned by the live call in plain language. If they have only Your notes, explain that it is private and help them find the owner of a relevant shared scope if they want access. Do not create a duplicate or use private notes as a silent fallback.

Offer to walk through finding account information, saving an agreed update, correcting information or getting access. Begin with the task they choose; do not create a demonstration record. Before a requested write, show the destination, proposed text, source and sensitivity label, explain the audience and wait for approval. If the tools do not reveal the full membership, route the person to Members and Groups instead of claiming to know every reader.

Respect `#memory` modes throughout. For web-only actions, explain the person's role and guide the clicks rather than claiming you completed an MCP action. Owners manage membership; authors or scope owners can publish a record. Changes to shared settings, deletion and bulk actions need their own specific approval, not permission inferred from setup.

For unresolved service or setup problems, name Rich Masters and link to [richard.masters@rakuten.com](mailto:richard.masters@rakuten.com). For account-scope access, name the relevant scope owner if discoverable. Suggest a reviewed, credential-free support message; do not automatically send it.

### Illustrated-guide link map

Use these section links for user-facing explanations. There are no anchors on the subheadings, so link to the enclosing section.

| What the person wants to do | Link to show |
|---|---|
| Understand scopes, records and who can read them | [How it fits together](https://memory.rmgops.com/guide#basics) |
| Set up Shared Memory | [Get started](https://memory.rmgops.com/guide#start) |
| Find their way around the web app | [Finding your way around](https://memory.rmgops.com/guide#layout) |
| Read, correct, label, publish or unpublish a record | [Records](https://memory.rmgops.com/guide#records) |
| Check membership, add a colleague or contact an owner | [Members](https://memory.rmgops.com/guide#members) |
| Change visibility, facets, ceiling or owner-only bulk settings | [Settings](https://memory.rmgops.com/guide#settings) |
| See who changed something and when | [History](https://memory.rmgops.com/guide#history) |
| Create a scope after checking for an existing one | [Creating a scope](https://memory.rmgops.com/guide#new) |
| Understand or manage access through groups | [Groups](https://memory.rmgops.com/guide#groups) |
| Disconnect an app, or manage a token for a script | [Apps and tokens](https://memory.rmgops.com/guide#tokens) |
| Investigate conflicting records | [Disagreements](https://memory.rmgops.com/guide#disagreements) |
| Ask Codex to find or save information; control memory use | [Using your agent](https://memory.rmgops.com/guide#agent) |
| Run or tidy a scope they own | [Owner responsibilities](https://memory.rmgops.com/guide#owners) |
| Resolve a common problem | [Questions and fixes](https://memory.rmgops.com/guide#faq) |

## Rollout checklist for Rich and IT

- Pilot with the Codex versions and organisation policies your users actually have. Verify the write-approval setting with a controlled test before broad deployment.
- Decide whether the rollout is MCP-only or includes the reviewed hooks. State that choice clearly in the distributed instructions.
- Each person signs in as themselves on each device. Never include credentials in the guide, installer, repository, screenshots or shared configuration.
- Verify `codex mcp login` and the app's **Authenticate** button with the Codex versions people actually have, including the 30-day and 90-day sign-in limits.
- Preserve existing config entries, plugins and instructions. Back up config changes and make re-running setup safe.
- Confirm a live read-only `list_scopes` call succeeds. Do not create production records as an onboarding test.
- Keep Rich Masters (richard.masters@rakuten.com) as the service/setup contact and identify the appropriate IT route for managed-client restrictions. Account-scope owners handle access to their scopes.
- Pilot the handout with an account manager who has not used Shared Memory: they should complete setup without editing a config, resume after the restart, recognise the verified connection and know how to find, save and correct account information. Check the browser sign-in and the **Allow** page in particular.
- Keep unattended scheduled jobs out of this personal sign-in. They need a service identity provisioned by the service administrator.

## References and verification

Service sign-in, connected apps, access and record actions are described in the [live illustrated guide](https://memory.rmgops.com/guide). Confirm service-specific changes and approved hook installation with Rich Masters at [richard.masters@rakuten.com](mailto:richard.masters@rakuten.com).

Codex Streamable HTTP servers, `codex mcp login` and tool-approval settings are documented in [OpenAI's MCP configuration guide](https://learn.chatgpt.com/docs/extend/mcp?surface=cli).

Maintained in `services/management-ui/public/codex-setup.md`; reviewed 14 October 2026 for the account-manager rollout and updated 4 November 2026 for browser sign-in. Distribute a copy of this maintained file or the current published download, not an old session snapshot. The token-based setup settings were checked against official Codex documentation, the live guide and the web-app source on 14 October 2026. The browser sign-in steps (`codex mcp login`, `--no-browser`, the app's **Authenticate** button, and how the **Allow** page names Codex) follow OpenAI's documentation and the server's behaviour, but have not yet been tried with the Codex versions people actually use: complete the pilot sign-in in the rollout checklist before handing this out. Each user's actual connection still requires their own browser sign-in and the live read-only test in step 5.