Skip to content

Codex repo-local .agents/skills are not discovered in project threads #3576

Closed as duplicate
Closed as duplicate
Codex repo-local .agents/skills are not discovered in project threads#3576
Labels
duplicateThis issue or pull request already exists

Description

@jakeleventhal
jakeleventhal
opened on Jun 26, 2026

Summary

When using T3 Code with a repo that contains Codex repo-local skills under .agents/skills/*/SKILL.md, the Codex composer only shows global/user skills. The repo-local skills are not discoverable via $skill in the thread composer.

This does not appear to be a Codex CLI discovery problem. If codex app-server is asked directly for skills with the repo cwd, it returns the repo skills correctly.

Reproduction

  1. Open a project in T3 Code whose repo contains local skills, for example:
    • /Users/jakeleventhal/Developer/myrepo/.agents/skills/*/SKILL.md
  2. Start or open a Codex thread for that project.
  3. Type $ in the composer to browse skills.

Actual

Only global/user Codex skills appear. Repo-local skills from .agents/skills are missing.

Expected

The composer should include skills discovered for the active project/thread cwd, including repo-local skills from .agents/skills.

Evidence

Direct Codex app-server probing works when using the project cwd:

"skills/list params": {
  "cwds": ["/Users/jakeleventhal/Developer/myrepo"],
  "forceReload": true
}

That returned repo-scoped skills such as:

audit-slow-sql-queries
create-linear-issue-from-diff
create-vercel-preview-deployment
frontend-conventions
generate-test-plan-from-diff
implement-linear-issue
investigate-marketplace-order-issue
review-changes
review-gh-pr-comments
trpc-procedure-usage
validate-changes
write-tests

Each had paths like:

/Users/jakeleventhal/Developer/myrepo/.agents/skills/<name>/SKILL.md

and scope: "repo".

Suspected cause

The composer appears to use provider status skills:

selectedProviderStatus?.skills ?? []

But Codex provider status is populated by a probe using the T3 Code server process cwd:

const probeResult = yield* probe({
  binaryPath: codexSettings.binaryPath,
  homePath: codexSettings.homePath,
  cwd: process.cwd(),
  customModels: codexSettings.customModels,
  environment: resolvedEnvironment,
})

Then the probe calls:

client.request("skills/list", {
  cwds: [input.cwd],
})

So the composer skill list is based on the T3 Code server cwd, not the active project/thread cwd. That makes it global/provider-scoped instead of project-scoped.

Possible fix

Make Codex skill discovery project-aware. For example:

  • Fetch skills/list using the active project or thread cwd when rendering composer skill suggestions.
  • Cache skills keyed by (providerInstanceId, cwd) rather than only provider status.
  • Keep provider status for account/model readiness, but avoid using it as the sole source for project-local skill suggestions.
  • Re-run skills/list for the active cwd when Codex emits skills/changed.

This would align the UI with Codex app-server behavior and allow .agents/skills to work in T3 Code project threads.

Activity

  1. jakeleventhal commented on Jun 26, 2026

    @jakeleventhal
    jakeleventhal
    on Jun 26, 2026
    ContributorAuthor

    Tried grok code and got same results

  2. StiensWout commented on Jun 30, 2026

    @StiensWout
    StiensWout
    on Jun 30, 2026 – with ChatGPT Codex Connector
    Contributor

    Additional reproduction from a T3 nightly server setup:

    • T3 nightly: t3 v0.0.29-nightly.20260630.690
    • t3 serve was running from a systemd service with WorkingDirectory=/srv/workspaces
    • The active project repo was /srv/workspaces/t3code
    • The repo contained a repo-local Codex skill at /srv/workspaces/t3code/.codex/skills/t3-contribute/SKILL.md

    Observed behavior:

    • Running Codex directly from /srv/workspaces/t3code included t3-contribute in the available skills.
    • Running Codex from /srv/workspaces did not include t3-contribute.
    • T3's provider cache only showed the default/global Codex skills when the service cwd was /srv/workspaces.
    • Temporarily changing the T3 service WorkingDirectory to /srv/workspaces/t3code made the provider cache include t3-contribute.

    That confirms the suspected cause in this issue: provider status skill discovery is based on the T3 server process cwd, not the active project/thread cwd. The workaround is to install the skill globally under ~/.codex/skills, but that makes a project-specific skill appear globally, which is not ideal.

  3. lmtr0 commented on Jul 4, 2026

    @lmtr0
    lmtr0
    on Jul 4, 2026

    I got skills for most of the work I do day to day. What would be the best approach to getting this merged and fixed?
    I'm willing to contribute.

    Also observed:

    ~ $ npx t3@nightly serve
# Server works and starts the system
# Doesn't show skills in .agents/skills

~/Code/repo $ npx t3@nightly serve
# Server works and starts the system
# Shows skills in ~/Code/repo/.agents/skills
# All other projects have all the skills in ~/Code/repo/.agents/skills

    In codex and opencode with the webui

    Desktop app shows the same behaviour

  4. lmtr0 commented on Jul 8, 2026

    @lmtr0
    lmtr0
    on Jul 8, 2026

    I've finished my implementation; hopefully it gets merged.
    I've open PRS for the base and codex impls, if they get merged, I'll open PRS for the cursor and opencode ones as well

  5. juliusmarminge commented on Jul 20, 2026

    @juliusmarminge
    juliusmarminge
    on Jul 20, 2026 – with ChatGPT Codex Connector
    Member

    Closing as a duplicate of #3040. Both reports describe repository-local .agents/skills missing because discovery is not scoped to the selected project cwd. No active superseding PR was found; implementation should stay attached to #3040.

  6. juliusmarminge
    added
    duplicateThis issue or pull request already exists
    on Jul 20, 2026
  7. juliusmarminge
    closed this as duplicateon Jul 20, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    duplicateThis issue or pull request already exists

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions