Skip to content

update chatgpt/codex agent plugin docs - #1529

Open
samhita-alla wants to merge 9 commits into
mainfrom
codex/openai-agent-plugins-docs
Open

update chatgpt/codex agent plugin docs#1529
samhita-alla wants to merge 9 commits into
mainfrom
codex/openai-agent-plugins-docs

Conversation

@samhita-alla

Copy link
Copy Markdown
Contributor

No description provided.

Signed-off-by: Samhita Alla <aallasamhita@gmail.com>
Copilot AI lite review requested due to automatic review settings August 28, 2026 12:48

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Updates the Flyte agent plugin documentation to reflect how ChatGPT’s Codex agent integrates with the official Flyte plugin, clarifying which MCP servers are automatically available vs. which must be configured locally.

Changes:

  • Clarifies that ChatGPT’s official Flyte plugin includes flyte-docs, while flyte-cluster remains a separate local MCP server for cluster access.
  • Updates compatibility and installation guidance to include a dedicated ChatGPT section, screenshots, and a ~/.codex/config.toml example.
  • Adds an explanatory section describing the division of responsibilities between skills and MCP servers.

Reviewed changes

Copilot reviewed 2 out of 4 changed files in this pull request and generated 1 comment.

File Description
content/user-guide/agents/build-mcp/flyte_mcp_server.md Updates the “prebuilt plugin” tip to describe ChatGPT’s official plugin behavior and manual flyte-cluster setup expectations.
content/api-reference/agent-plugins.md Expands compatibility + installation docs for ChatGPT (Codex), adds manual flyte-cluster config snippet, and clarifies skills vs MCP servers.
Suppressed comments (1)

content/api-reference/agent-plugins.md:68

  • Image alt text is too vague; consider describing what the image depicts so it remains meaningful in non-visual contexts.
![Local MCP](../_static/images/api-reference/local_mcp.png)

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

Comment thread content/api-reference/agent-plugins.md Outdated
@github-actions

github-actions Bot commented Aug 28, 2026

Copy link
Copy Markdown

GHA build & deploy preview

Built by .github/workflows/build-pr.yml and deployed to the docs CF Pages project by .github/workflows/deploy-pr-preview.yml.

Branch alias https://pr-1529-codex-openai-agent-p.docs-dog.pages.dev
This commit https://18fb72b6.docs-dog.pages.dev
Commit SHA 336832cb9a903b79468c532f612528743ed7658a

Updated automatically on every push.

Signed-off-by: Samhita Alla <aallasamhita@gmail.com>
Signed-off-by: Samhita Alla <aallasamhita@gmail.com>
@samhita-alla
samhita-alla marked this pull request as draft August 28, 2026 12:58
Signed-off-by: Samhita Alla <aallasamhita@gmail.com>
ppiegaze added a commit to unionai/unionai-docs-infra that referenced this pull request Aug 30, 2026
…king

unionai/unionai-docs#1529 added an image whose rendered src 404s on its own
Cloudflare preview, and all fifteen of its checks passed. Every existing check
reads a different artifact than the browser does:

  check_images.sh          reads SOURCE markdown, and resolves relative paths
                           from the markdown file's directory -- not the page URL
  check_internal_links.py  reads content/, and skips images by design
  check_generated_links.py reads the markdown twins, which carry no <img>
  check-asset-refs.sh      matches (css|js) only, anchored at `="/`, under `|| true`
  validate_urls.py         sees images but treats any relative path as valid

Hugo's render hooks rebase an image src, so a path can be correct in the
markdown and wrong in the HTML. Only the built tree shows what ships.

Two things make images harder than links, and both are encoded as tests:

1. Resolution is against the PAGE's URL. The pre-#290 defect went one level too
   low, #290 itself went one level too high on _index.md pages. Both directions
   must fail, which is only true if resolution follows the browser.

2. A wrong path often does not 404. #290's index defect produced
   /docs/v2/_static/..., which 302s to an HTML page -- a status-code check would
   have called it fine. So an HTML or directory target is a failure with its own
   reason, not a hit.

Found and fixed a false-pass in this tool's own resolver while testing it:
posixpath.normpath CLAMPS a leading `..` at the root of an absolute path,
turning /a/../../../b into /b. A clamped path can name a file that exists, so
the escape would have passed rather than merely been mislabelled. The `..`
segments are now walked by hand.

Verified against a real `make dist`: 2787 images, zero broken, so no baseline
ratchet is needed. Verified it CATCHES the defect by running it over real Hugo
output built from three template versions -- it fails on origin/main, fails on

Not yet wired into CI. The docs build runs in unionai-docs, so firing this needs
one line after `make check-generated-links` in build-pr.yml and
build-and-deploy.yml there. Deliberately left for a separate PR.

Co-Authored-By: docsy <docsy@union.ai>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FuWqf82dbqzyqKKkXuF1MY
Signed-off-by: Peeter Piegaze <1153481+ppiegaze@users.noreply.github.com>
ppiegaze added a commit to unionai/unionai-docs-infra that referenced this pull request Aug 30, 2026
…king (#295)

unionai/unionai-docs#1529 added an image whose rendered src 404s on its own
Cloudflare preview, and all fifteen of its checks passed. Every existing check
reads a different artifact than the browser does:

  check_images.sh          reads SOURCE markdown, and resolves relative paths
                           from the markdown file's directory -- not the page URL
  check_internal_links.py  reads content/, and skips images by design
  check_generated_links.py reads the markdown twins, which carry no <img>
  check-asset-refs.sh      matches (css|js) only, anchored at `="/`, under `|| true`
  validate_urls.py         sees images but treats any relative path as valid

Hugo's render hooks rebase an image src, so a path can be correct in the
markdown and wrong in the HTML. Only the built tree shows what ships.

Two things make images harder than links, and both are encoded as tests:

1. Resolution is against the PAGE's URL. The pre-#290 defect went one level too
   low, #290 itself went one level too high on _index.md pages. Both directions
   must fail, which is only true if resolution follows the browser.

2. A wrong path often does not 404. #290's index defect produced
   /docs/v2/_static/..., which 302s to an HTML page -- a status-code check would
   have called it fine. So an HTML or directory target is a failure with its own
   reason, not a hit.

Found and fixed a false-pass in this tool's own resolver while testing it:
posixpath.normpath CLAMPS a leading `..` at the root of an absolute path,
turning /a/../../../b into /b. A clamped path can name a file that exists, so
the escape would have passed rather than merely been mislabelled. The `..`
segments are now walked by hand.

Verified against a real `make dist`: 2787 images, zero broken, so no baseline
ratchet is needed. Verified it CATCHES the defect by running it over real Hugo
output built from three template versions -- it fails on origin/main, fails on

Not yet wired into CI. The docs build runs in unionai-docs, so firing this needs
one line after `make check-generated-links` in build-pr.yml and
build-and-deploy.yml there. Deliberately left for a separate PR.



Claude-Session: https://claude.ai/code/session_01FuWqf82dbqzyqKKkXuF1MY

Signed-off-by: Peeter Piegaze <1153481+ppiegaze@users.noreply.github.com>
Co-authored-by: docsy <docsy@union.ai>
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
Signed-off-by: Samhita Alla <aallasamhita@gmail.com>
@samhita-alla
samhita-alla marked this pull request as ready for review August 31, 2026 05:45
@samhita-alla

Copy link
Copy Markdown
Contributor Author

hey @ppiegaze, would you mind reviewing this PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants