Summary
In Codex sessions using the PostHog MCP/plugin, agents frequently conclude that an accessible project cannot be accessed when it is not the current active project. The project is accessible, and a follow-up prompt usually gets the agent to realise it should call switch-project first.
This happens repeatedly in coding sessions even when local repo instructions explicitly say to use the intended PostHog project and to verify/switch projects before querying.
Observed behaviour
- Codex starts with the PostHog MCP active project set to one project, for example a staging/pre-production project.
- The user asks Codex to query another project in the same organisation, for example production, sometimes providing the exact project ID.
- The agent often responds as if it does not have access to that project.
- After the user prompts again and explicitly says it does have access or should check/switch, the agent can discover the project and/or switch successfully.
Expected behaviour
When the user provides a target PostHog project name or project ID that differs from the active project, the Codex/PostHog plugin instructions should strongly guide the agent to:
- list or retrieve accessible projects if needed,
- call
switch-project with the requested project ID, and
- only report an access problem after that switch/retrieve attempt fails.
Why this is confusing
The MCP/tool context tells the model the current active project, but in practice the user may have access to multiple projects in the same organisation. The model seems to treat "not currently active" as "not accessible" unless pushed again.
Suggested improvement
Could the Codex plugin/MCP prompt or the switch-project tool guidance be made more explicit? For example:
- If a user asks for a different project by name or ID, do not infer lack of access from the active project context.
- First use
projects-get, project-get or switch-project as appropriate.
- Only say the project is inaccessible if those calls fail.
Setup
- Codex with the PostHog plugin installed
- PostHog MCP server configured
- Organisation has multiple projects/environments available to the same user
- Repro occurs frequently in normal coding-agent sessions
Summary
In Codex sessions using the PostHog MCP/plugin, agents frequently conclude that an accessible project cannot be accessed when it is not the current active project. The project is accessible, and a follow-up prompt usually gets the agent to realise it should call
switch-projectfirst.This happens repeatedly in coding sessions even when local repo instructions explicitly say to use the intended PostHog project and to verify/switch projects before querying.
Observed behaviour
Expected behaviour
When the user provides a target PostHog project name or project ID that differs from the active project, the Codex/PostHog plugin instructions should strongly guide the agent to:
switch-projectwith the requested project ID, andWhy this is confusing
The MCP/tool context tells the model the current active project, but in practice the user may have access to multiple projects in the same organisation. The model seems to treat "not currently active" as "not accessible" unless pushed again.
Suggested improvement
Could the Codex plugin/MCP prompt or the
switch-projecttool guidance be made more explicit? For example:projects-get,project-getorswitch-projectas appropriate.Setup