GitLab plugin: add CI job artifact access and whole-artifact download to sandbox

What variant of Codex are you using?

Web / ChatGPT GitLab (Beta) plugin (OpenAI-curated), currently shown as version 0.1.4-f60f8fa9db65.

What feature would you like to see?

Please add CI/CD artifact access to the OpenAI GitLab plugin/connector.

There are two useful levels:

1. Minimum parity with GitLab's official MCP server

   • expose artifact metadata from jobs/pipelines;
   • add a get_artifact_file-style read for a file inside a job artifact archive.

2. Whole-artifact transport for agent execution workflows

   • add a download_job_artifact-style action that downloads the complete artifact archive using the connector's existing authenticated GitLab session;
   • return it as a reusable ChatGPT file reference so it can be materialized into the sandbox and unpacked there.

Conceptually:

GitLab private repo / CI
        ↓ authenticated connector
job artifact archive
        ↓
reusable ChatGPT file reference
        ↓
materialize into sandbox
        ↓
unpack / grep / build / test

This would let the connector remain the authenticated transport layer while keeping GitLab OAuth/PAT credentials out of the sandbox.

Why this matters

The current OpenAI GitLab connector already supports projects, repository files, pipelines, jobs, job traces, test reports, etc., but its current tool surface does not expose a job-artifact content/download action.

That becomes a practical blocker for repository-scale agent workflows. Reading a private repository file-by-file through connector actions is much less useful than transferring an immutable source snapshot/artifact into the sandbox, where the agent can use a normal filesystem, rg, AST tooling, builds, linters, and tests.

This also creates an asymmetry with the GitHub connector, which already has a workflow-artifact download path that can return a reusable file reference.

GitLab upstream has already implemented the MCP-side artifact capability

GitLab completed its CI artifact access work on 2026-09-15:

• Issue: https://gitlab.com/gitlab-org/gitlab/-/work_items/585022
• MR !254893: add artifact facets to get_job / get_pipeline
  https://gitlab.com/gitlab-org/gitlab/-/merge_requests/254893
• MR !254894: add get_artifact_file
  https://gitlab.com/gitlab-org/gitlab/-/merge_requests/254894

GitLab's implementation already addresses authorization, artifact access settings, path validation, bounded reads, binary handling, and AI file-exclusion concerns.

The OpenAI GitLab plugin appears to use its own connector action catalog rather than automatically inheriting GitLab's /api/v4/mcp tool surface, so these upstream additions are not currently visible in the ChatGPT plugin.

Suggested API shape

For text/file reads, OpenAI could mirror GitLab's new get_artifact_file behavior.

For the stronger source-snapshot workflow, something like:

download_job_artifact(project_id, job_id)
  -> reusable file reference

would be enough. The sandbox should never receive the connector's GitLab credential; only the downloaded artifact bytes/file reference should cross that boundary.

Security / integrity notes

For source-snapshot use cases, it would be helpful if callers can verify/bind:

• project/repository
• ref
• commit SHA
• job ID / pipeline ID
• artifact name / size / expiration
• artifact digest when available

That supports fail-closed stale-snapshot detection before the artifact is used for repository analysis or test execution.

Additional information

I searched the public openai/codex issue tracker and openai/plugins repo for an existing GitLab artifact/download request and did not find a matching feature request.

The public OpenAI plugin manifest work is here:
https://github.com/openai/plugins/pull/351

That PR points at the same GitLab connector app ID used by the installed ChatGPT plugin, but the backend connector capability surface appears to evolve independently from the public plugin manifest.

Start with the connector action catalog and the public plugin manifest work in PR #351, then compare the proposed actions with GitLab work item 585022 and MRs !254893 and !254894. Determine how artifact metadata, file reads, or whole-artifact downloads fit the existing authenticated connector and reusable file-reference flow. Done means an agreed API and security boundary, including the stated snapshot metadata and credential isolation requirements.