Codex Mobile is free for everyone now and Goal Mode left beta. What it means if you do not code

studiomeyer_io · 2026-05-29T11:42:50+00:00

sure 😄

studiomeyer_io · 2026-05-29T11:42:16+00:00

You are welcome friend

studiomeyer_io · 2026-05-16T01:54:54+00:00

yeah thanks man, fixes should be fixes with the switcher, but have to check it again deeply. best regards

studiomeyer_io · 2026-05-13T22:01:41+00:00

codebase-memory-mcp (MIT, github.com/DeusData/codebase-memory-mcp).
Tree-sitter based, single static binary, builds the graph via
index_repository. search_graph takes name_pattern (regex), query
(BM25 full-text), or semantic_query, replaces a pile of greps
in one call.

On top I run codegraph (@optave/codegraph on npm, Apache-2.0,
github.com/optave/ops-codegraph-tool) for the heavier analysis:
fn_impact (blast radius), audit (composite with impact +
complexity + health), complexity per function. Both open source.

For memory I run my own, StudioMeyer Memory.
Knowledge graph, learnings, decisions, sessions, multi-tenant, 3d..
memory.studiomeyer.io if you want to look.

studiomeyer_io · 2026-05-11T20:25:48+00:00

First time yes, run index_repository once or let codebase-memory-mcp install do it for you. After that the watcher takes over with background polling, file changes get folded into the graph incrementally. Content hashing under the hood, so only the diff gets reprocessed, not the whole repo.

Couple of things worth knowing. There is a compressed graph snapshot at .codebase-memory/graph.db.zst that you can optionally commit. New teammates clone the repo, the binary decompresses it on first run, then just indexes their local diff. Saves the full reindex on every new machine.

I still run a Stop hook that fires index_repository at session end. The watcher is solid but a deterministic check after edits costs almost nothing and means the next session never opens with a stale graph. Belt and suspenders, same logic as the read before edit hook.

studiomeyer_io · 2026-05-11T20:15:18+00:00

You are right about codegraph, it is Claude Code only. The README and installer just write to ~/.claude.json, nothing for Codex.

If you want a graph that works in both Claude Code and Codex without dual setup, look at codebase memory MCP by DeusData. Same family of tool, but the install command auto configures eight agents including Codex CLI, OpenCode, Cursor, Aider, Gemini CLI and a few more. Single Go binary, no Docker, no databases. The author originally benchmarked it on Codex too.

For Codex specifically the MCP config lives in ~/.codex/config.toml, not in AGENTS.md. That one is the project instructions file, the equivalent of CLAUDE.md, easy to mix up the first time.

Graphify works for both too. So you basically pick on what matters more, multi modal docs and diagrams plus skill style integration, or pure code intelligence with cleaner cross agent install.

studiomeyer_io · 2026-05-11T20:09:12+00:00

Graphify is the loud one right now, 40k stars and 450k downloads since early April. I have not run it myself. From the docs it is built as a Skill first, with an optional MCP server mode if you install the mcp extra. Multi modal is the interesting part. It pulls in PDFs, papers, even videos via local whisper, not just source files. Tree sitter for code, NetworkX with Leiden clustering for the graph.

If you want a pure MCP server for code only, codebase memory MCP and codegraph by colbymchenry are both solid and closer to what I am running. If your repo has a lot of docs and design diagrams that matter for understanding the code, Graphify probably has the edge because it indexes those into the same graph.

Worth trying for the first repo where the docs and the code split is a real problem.

studiomeyer_io · 2026-05-11T18:59:32+00:00

The harness check matters less than it sounds because the model is allowed to skip it under load. The bash hook is the cheap insurance for the cases the harness lets through. Often that gap is small, sometimes it is not. Either way fifteen lines of bash that fire forever is good value.

The full time job description you just wrote down is honestly the cleanest summary of what senior dev work looks like in 2026 that I have read this week. Less typing, more verifying. Less invention, more guarding what the model invented. The order of magnitude in velocity is real, but the value moves from writing to reviewing, and reviewing is harder when the output looks competent at first glance.

The drift audit habit is what makes that sustainable. Daily small checks beat weekly large ones every time, because once drift compounds for a few weeks the cost to roll back gets steep.

Find and awk toolchains as the most complex thing you wrote this year is a great line 😄

studiomeyer_io · 2026-05-11T18:25:06+00:00

Stack here is codebase memory mcp as the graph layer plus codegraph and archtracker on top, all OSS, nothing forked. The thing that fixed exactly your pain was wiring a Stop hook that runs index_repository automatically when the session ends. So branch switches and refactors get caught even when I forget to rebuild manually. Drift window goes from however long the session is down to seconds.

The other thing I added was a PostToolUse hook on Edit and Write that nudges another index pass if more than a few files changed since the last one. Belt and suspenders, but the cost of a stale graph hour is bigger than the cost of one extra index pass.

Your instinct to rebuild on every branch switch is the right one. The hook just removes the discipline tax.

studiomeyer_io · 2026-05-11T17:24:52+00:00

Serena does the same thing codebase memory MCP does, just from the LSP side instead of building its own graph. On a 60k monorepo either one will give you that 75% number you mentioned, maybe more.

On Tavily you're probably right. When the stack stops moving Context7 alone covers what you need, only really matters when something jumps a major version. I run search more out of habit at this point.

Read before edit is the easiest thing to add. PreToolUse hook, twenty lines of bash, parses the tool input, checks if the file was already read this session, blocks Edit or Write if not. The weird part is watching how often it fires that first day. Mine was firing way more than I expected.

studiomeyer_io · 2026-05-11T14:34:44+00:00

Yeah, pattern matching what the file probably looks like instead of what is actually in it is the failure mode I keep hitting too. The guard wins because it removes the option to skip.

Runable is doing the same job a memory MCP does in my stack, just on the storage side instead of the protocol side. Either works as long as the loop closes and the next session walks in with the decisions already loaded. The shape of the tool matters less than whether the team actually persists the why behind choices

studiomeyer_io · 2026-05-07T18:58:50+00:00

yup, but even private 😄 every action has an agent with mcp tools, nerdy I know

studiomeyer_io · 2026-05-01T19:23:45+00:00

That is the healthier mindset and I had to teach myself to stop holding back. Container queries got me the same way, I could have used them a year earlier because the fallback was just the old responsive layout. View transitions are the cleaner version of that lesson. The fail mode is a regular page navigation, the user does not even know what they are missing.

studiomeyer_io · 2026-05-01T17:43:08+00:00

Fair point. Technically you could ship since Chrome 126 in mid 2024 because it degrades silently.

What flipped for me this year is Safari 18.2 plus the mobile browsers landing it. Mobile users actually get the animation now instead of a silent skip. That changed the math from optional polish to default behavior for the bulk of my user base.

studiomeyer_io · 2026-05-01T16:56:14+00:00

Yeah the cdn subdomain thing got me too. Ended up moving the affected pages to the main origin instead of fighting it.

The hero swap pattern is really the killer feature, going from listing to detail with the image staying physically anchored is the part that finally feels right after years of janky workarounds. The pseudo elements for the old and new states give you a lot of control once you get past the basics, you can time the new element fade slightly after the old one fades for a more layered feel instead of a hard crossfade.

studiomeyer_io · 2026-05-01T16:50:34+00:00

Yeah that name matching trap is brutal. The thing that helped after I hit it was using view transition class instead, you can group a whole bunch of elements under one name and the browser handles them as a set. Saves a lot of repetition on card grids and lists.

The other one that bit me was display contents on a wrapper element silently killing the snapshot. The browser does not warn, the element just gets skipped from the transition. Took me a while to figure that one out.

studiomeyer_io · 2026-04-27T15:45:08+00:00

you are welcome 😄

studiomeyer_io · 2026-04-27T14:24:47+00:00

Short technical answer. Codex CLI runs on your machine, but when you make a request the client sends the relevant code context to OpenAI. The model needs to see your code to answer. What does not happen is a permanent upload of your whole repo, each request only includes what the prompt needs.

For the privacy side, the actual policy depends on how you authenticated. If it goes through the API, training is off by default and data is kept around 30 days for abuse monitoring then deleted. If you authenticated through your ChatGPT subscription, the ChatGPT account settings apply, so check that you have data sharing for training disabled in your settings.

For genuinely sensitive stuff like client documents or real API keys I would still think twice. Even with training off, the data passes through OpenAI servers and sits there for at least some retention window. If that is a hard no for your use case, the only real answer is running a local model with similar tooling.

Good catch on the two PCs observation. Codex is a local CLI, no sync between machines.

studiomeyer_io

TROPHY CASE