[Bug]: Repo-local Codex skills do not appear in T3 Code $ skill picker #3040

Activity

1. laceyp99

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Jun 11, 2026
2. jakeleventhal commented on Jul 20, 2026

   

   jakeleventhal

   on Jul 20, 2026

   Contributor

   More actions

   @juliusmarminge #3982 my PR here solves this for both codex and Grok
3. Rido

   added a commit that references this issue on Jul 25, 2026

   fix: discover project-level Claude skills for the picker in the deskt…

   ...

   ce84ea7
4. Cedillin commented on Jul 27, 2026

   

   Cedillin

   on Jul 27, 2026

   More actions

   Confirming on macOS with the packaged nightly (0.0.29-nightly.20260727.919, t3codeCommitHash f4c394323d45, codex-cli 0.145.0), and adding a repro that isolates the variable to cwd alone.

   Driving codex app-server directly, the only thing that changes between a hit and a miss is the cwds argument:

   send({"jsonrpc":"2.0","id":2,"method":"skills/list",
         "params":{"cwds":[CWD],"forceReload":True}})

   cwds	result for a repo-local .agents/skills/migration-workflow
   ["/Users/david/projects/maat/workspace-app"]	found — scope: "repo", path: <repo>/.agents/skills/migration-workflow/SKILL.md
   ["/"]	absent (122 skills, all global)

   So Codex itself is fine; the skill file, frontmatter and agents/openai.yaml are all fine. What T3 passes is the problem — from apps/server/dist/bin.mjs in the shipped asar:

   const probeResult = yield* probe({
     binaryPath: codexSettings.binaryPath,
     ...
     cwd: process.cwd(),        // <-- server process cwd, not the open project

   and on the receiving side, a cwds entry that matches nothing falls back to flattening every entry, which quietly hides the miss:

   const matchingEntry = response.data.find((entry) => entry.cwd === cwd);
   return (matchingEntry ? matchingEntry.skills : response.data.flatMap((e) => e.skills))

   In the packaged macOS app that cwd is /:

   $ lsof -a -p <t3code-pid> -d cwd -Fn
   n/
   

   which is why deleting ~/.t3/caches/codex.json and restarting doesn't help — the rebuild asks the same wrong question.

   Same root cause on the Claude driver (#4544): discoverClaudeSkills(config, cwd, env) scans <cwd>/.claude/skills with that same ServerConfig.cwd. So this isn't Codex-specific — every driver's project scope is dead in packaged builds. #3982 covers codex + grok and #4546 covers claude; worth landing them together.

   Workaround that survives app restarts, if anyone needs it before those merge — symlink the repo skill into the global root the probe does scan:

   ln -s <repo>/.agents/skills/<name> ~/.codex/skills/<name>
   ln -s <repo>/.agents/skills/<name> ~/.claude/skills/<name>

   It then shows up as scope: "user". Nightly updates don't clobber it, since it lives outside the app bundle.
5. mrdowdeswell commented on Aug 11, 2026

   

   mrdowdeswell

   on Aug 11, 2026

   More actions

   This happens too when running npx t3@nightly using Claude Code as the harness, but only if npx is not run in the root folder of the project. If it is, the skills appear using the $ picker. The snag is that if you change to a different project, those same skills follow you there and they aren't updated with the new project's local skills.

   1. Create local skills in Repo-A/.claude/skills/ and Repo-B/.claude/skills/.
   2. Open a terminal inside Repo-A and run npx t3@nightly.
   3. Type $ in the composer and Repo-A skills show up correctly.
   4. Switch the workspace context in T3 Code to Repo-B.
   5. Type $ in the composer and Repo-A's skills are still displayed, while Repo-B's local skills are apparently ignored.

   Tested on MacOS 15.7, 0.0.34-nightly.20260811.1068, Claude Code v2.1.227
6. t3dotgg

   marked [Bug]: local skills in .agents/ folder for codex not being picked up in $ skill invocation #7710 as a duplicate of this issue on Aug 22, 2026
7. BenWortley commented on Aug 25, 2026

   

   BenWortley

   on Aug 25, 2026

   More actions

   Confirmed on macOS with the packaged Nightly desktop app.

   Environment

   • T3 Code: 0.0.34-nightly.20260825.1184
   • Commit: 5d7665396083d285132d67038813862a93337ca5
   • macOS 26.6.2, Apple Silicon
   • Codex provider reported by T3: 0.149.1

   Reproduction

   1. Open a repository containing 39 valid project-local skills under <repo>/.agents/skills/<skill>/SKILL.md.
   2. Confirm the same skills appear in the official Codex app.
   3. Open the repository in the packaged T3 Code Nightly desktop app.
   4. Type $ in the composer.

   Only global/plugin skills appear. Completely quitting T3 Code and performing a fresh reinstall does not change the result.

   Additional evidence

   • The packaged T3 server process has <home> as its cwd rather than the active repository.
   • <home>/.t3/caches/codex.json contains 19 global/plugin skills and zero project-scoped skills.
   • In the installed source, checkCodexProviderStatus passes process.cwd() to the Codex probe. That value is subsequently sent to skills/list as cwds: [input.cwd].
   • Consequently, the packaged desktop app requests skills relative to <home>, while the official Codex app requests them relative to the active repository.

   This appears to be the same cwd-scoping problem described here, and it remains reproducible in the August 25 Nightly. Related: #6449 and the open fix in #7909.
8. t3dotgg commented on Aug 27, 2026

   

   t3dotgg

   on Aug 27, 2026

   Member

   More actions

   Thanks for the detailed report. This looks like the same issue tracked in issue #6449.

   Issue 6449 explicitly names the Codex skills/list cwd problem as well as Claude discovery. Issue 3040 supplies an A/B probe where changing only cwds finds or loses the same repository skill, and later comments reproduce the same startup-directory leakage across Claude projects. Current main still sends process.cwd to Codex discovery and ServerConfig.cwd to Claude discovery. This is one missing active-project scope, not two provider-specific missing-directory formats.

   I'm closing this as a duplicate as part of an automated pass on all open issues. I linked this report from issue #6449 so its extra details remain available. This does not mean the underlying bug is fixed.

   👍React with 👍1Reacted by Patrick Lacey
9. t3dotgg

   closed this as not plannedon Aug 27, 2026