Codex custom-provider v0.7.5 test cohort: same workspace → recall, other workspace → isolated

[hjqcan]

GoodMemory 0.7.5 has a maintainer-run compatibility smoke for Codex custom
Responses providers. I am looking for non-maintainer users to repeat the
same/other-workspace check with a real third-party or local provider.

An install, star, download, directory listing, or maintainer-run mock does not
count as adoption. A reproducible result from someone else does.

Maintainer baseline (not adoption)

On 2026-08-22, Codex CLI 0.149.0 and the published goodmemory@0.7.5 tarball
were tested in an isolated macOS arm64 environment against a deterministic
loopback Responses provider.

• workspace A stored one explicit ORCHID-742 fact
• a fresh Codex request from workspace A contained that fact exactly once
• the same request from workspace B contained it zero times
• both turns completed through the custom provider
• writeback stayed off; startup and the turns created no durable writes

Reproducible fixture, commands, sanitized request summaries, and SHA-256
receipts:
https://gist.github.com/hjqcan/565d7d1058420fdb36c53d52eac2ff87

This proves a maintainer-run request-injection boundary only. It does not prove
that a real custom provider uses the context correctly, that Codex native
Memories work with that provider, or that GoodMemory improves coding outcomes.
The independent-user count is currently zero.

Requirements

• Codex CLI with a non-default model_provider using the Responses API
• Node.js 20 or newer
• Bun 1.3.14 or newer
• GoodMemory 0.7.5
• a disposable project containing no sensitive data

Do not post provider credentials, raw system prompts, private files, or the full
captured request body.

Setup

Review the planned host changes first:

npm install -g goodmemory@0.7.5
goodmemory setup \
  --host codex \
  --activation-mode global \
  --writeback off \
  --dry-run \
  --no-interactive \
  --json

If the dry run only shows the expected GoodMemory host config, hooks, and MCP
registration, rerun without --dry-run. Keep your existing top-level
model/model_provider and [model_providers.<id>] settings; do not paste
credentials into this discussion.

In project A, write one synthetic fact:

goodmemory remember \
  --host codex \
  --workspace-root "$PWD" \
  --message 'Remember that this disposable project is blocked on ORCHID-742 smoke verification.' \
  --role user \
  --extraction-strategy rules-only \
  --json

goodmemory status codex --workspace-root "$PWD" --json

Start a fresh Codex session in project A and ask:

What deployment marker is blocking this workspace? Return only the marker, or UNKNOWN if no relevant fact is available.

Then start another fresh session under a different absolute project path and
ask the identical question. Project B should answer UNKNOWN, not
ORCHID-742. Also run goodmemory status in project B; it should report a
different workspace scope and zero facts.

Please report

Reply with:

• OS and architecture
• Codex CLI, GoodMemory, Node.js, Bun, and npm versions
• provider product and model name
• the non-secret model_provider, base_url host, and wire_api values
• the write receipt: accepted/rejected and reason
• project A and project B workspace IDs and fact counts
• the two model answers
• whether either startup/turn created an unintended durable write
• sanitized error text if any step failed

A valid negative result is useful. If the provider ignores the injected fact,
loops on tools, rejects the request shape, or crosses scopes, report that rather
than retrying until the demo looks successful.

GoodMemory Codex setup contract:
https://github.com/hjqcan/GoodMemory/blob/v0.7.5/docs/GoodMemory-Codex-Handoff-Setup-Guide.md

Related Codex native Memories request:
openai/codex#39272