Troubleshooting
Runtime cannot find a Skill or Agent
Verify the runtime, project or global scope, installed content, and supported projection when a successful install is not discoverable.
Use this page when Kit installation succeeds but the runtime does not list or recognize an expected Skill or Agent.
Match the runtime session to the install
Confirm all four details from the original install output:
- Kit name.
- Target runtime:
claude-codeorcodex. - Scope: the current project or
--global. - Selected Skills, including any
--skillsor--exclude-skillsfilter.
A project install is discovered from that project. A global install is discovered from the runtime's user profile. Start a new runtime session after installation so it loads the current inventory, and use that runtime's documented discovery surface.
For example, invoke a Skill named ak:cook with the runtime-specific syntax:
/ak:cook Check this project # Claude Code
$ak:cook Check this project # CodexAgents use a different surface. Claude Code dispatches installed subagents;
Codex loads TOML-defined Agents and exposes their agent_<slug> runtime tools.
The absence of / or $ invocation syntax does not mean an Agent is missing.
Check the destination that matches the selected delivery:
| Delivery | Project scope | Global/user scope |
|---|---|---|
| Claude native | <project>/.claude/ | ~/.claude/ |
| Claude plugin | <project>/ak-<kit>/ | ${AGENTKIT_PLUGIN_DIR:-~/.claude/plugins}/ak-<kit>/ |
| Codex Skills | <project>/.agents/skills/<name>/ | ~/.agents/skills/<name>/ |
| Codex Agents, config, and hooks | <project>/<kit>/.codex/ | ${CODEX_HOME:-~/.codex}/ |
Check the adapter, not only file presence
ak doctor --adapter claude-code --json
ak doctor --adapter codex --jsonRun the command for the target you installed. File presence alone does not prove
that runtime registration or configuration is valid. Inspect the report's
adapter checks and data.healthy; the default doctor command still exits 0
for an unhealthy report. On Codex, use doctor as an adapter-health signal, not
as the only proof of the installed Skill inventory; verify discovery inside the
runtime too.
Read codex_install_provenance as a whole-home classification, not a Kit
inventory check. ${CODEX_HOME:-~/.codex} is a shared, user-owned root, so this
row is healthy when it contains user content and does not require a whole-home
AgentKit marker. A legacy marker is not current ownership evidence and its
absence is not a reason to initialize, replace, or delete the Codex home.
Per-Kit manifests and ownership records govern AgentKit content instead.
For Claude Code installs, use the matching read-only audit described in Kit
installation problems. If audit exits 1, resolve the
reported drift before debugging runtime discovery.
Read active Claude hook surfaces
The Claude Code hook_registration and hook_log checks inspect every active
install surface they can attribute in the current context: user or project
scope, and native or plugin delivery. In JSON, registration details list
kit, scope, mode, manifest or settings paths, and missing registrations
under details.surfaces; hook-log details list each active log under
details.logs.
A missing hook log is healthy on a fresh surface and does not prove that the Skill or Agent is missing. A registration warning identifies the affected surface. When Doctor prints one unambiguous repair command, use that exact target, scope, and delivery mode; otherwise repair each named surface explicitly rather than refreshing a different route.
Recover Claude plugin activation
Plugin files are not enough to activate a Claude Code plugin. If the install
warns that the claude CLI was not found, run the two complete commands printed
in that warning, in order:
claude plugin marketplace add "<marketplace-source>" --scope <project-or-user>
claude plugin install <kit>@<marketplace> --scope <project-or-user>Use the exact source, plugin reference, and identical scope from the install output. The first command registers the marketplace; the second records the plugin installation in Claude Code. Then close and reopen Claude Code in the intended project. Also start a fresh Claude Code session after switching between native and plugin delivery; an existing session does not reload that mode.
Recover Codex Agent tools
Codex Skills and Agents have separate discovery paths. Skills are native files
under .agents/skills and do not require the AgentKit MCP server. Agents are
TOML files exposed as agent_<slug> tools by the registered AgentKit runtime.
Inspect codex_mcp_registration in the Codex doctor report. If it says
[mcp_servers.ak-agent-runtime] is missing, register it once:
ak doctor --adapter codex --json
ak codex-agent-runtime register
ak codex-agent-runtime serve --list-onlyRegistration idempotently updates ${CODEX_HOME:-~/.codex}/config.toml and
preserves other MCP server entries. The list-only command is read-only and must
name the expected Agents before you continue. For project-staged Agents, run
the check from the project root with the project as the staging root:
ak codex-agent-runtime serve --list-only --plugin-root .This override verifies <project>/<kit>/.codex/agents/; it does not move those
Agents into user scope or rewrite the registered server. If only the overridden
check finds them, resolve the scope mismatch instead of copying TOML files.
After registration or scope correction, close and start a fresh Codex session
so it reloads MCP configuration.
If Codex cannot find ak:team
This absence is intentional. The Codex adapter excludes the Engineer
ak:team Skill because Codex does not provide the complete Agent Teams
lifecycle that workflow requires. It does not install a $ak:team invocation
or silently substitute ordinary Codex subagents.
The install summary reports
Capabilities excluded (unsupported on this target) and names ak-team; JSON
uses capabilityExclusions and capabilityExclusionSummaries. A refresh removes
an older AgentKit-owned ak-team copy only when its recorded ownership hash
still matches. Modified, unowned, or linked copies are preserved, but they are
not made supported by remaining on disk. Choose another Codex workflow or use
ak:team in a runtime where the Skill is projected and the live team lifecycle
is available.
If the install says Hooks were dropped
On a Codex target, a successful install can include this exact summary:
[!] Hooks dropped (unsupported on this target): 1 group - see warningsThis is a supported partial-projection diagnostic, not a hidden install failure. It means the named hook group uses a matcher for Claude tools that has no equivalent in the Codex tool namespace, so that group and its named handlers were not projected. Other compatible hooks and installed Skills or Agents remain separate results; check their lines in the same install summary.
The number counts matcher groups, not files or scripts. JSON install output
reports the same limitation in hooksDropped and droppedHookSummaries. The
following warning names the affected event, matcher, and handlers.
For Engineer, the PostToolUse group with matcher
Agent|Task|TodoWrite|TodoRead invoking session-state.cjs is not projected,
so there is no mid-session task-state refresh from that group. Compatible
Edit|Write and * groups remain, and task-state refresh still runs at the
supported Stop and SubagentStop turn and subagent boundaries. Do not retry
with --force, copy Claude hook configuration into Codex, or delete either
runtime home to remove the warning.
A Codex hook fails on Windows
An eligible .cjs hook inside the resolved Codex home can run from a path with
spaces through an AgentKit-managed sibling .cmd shim. A spaced path outside
the Codex home, a path with cmd.exe metacharacters, a non-ASCII shim basename,
or unsafe or non-ASCII baked arguments remains unsupported and produces a
warning. A path without spaces continues to use the direct command.
Do not move an external hook into the Codex home or hand-edit the generated shim as a workaround. Keep the warning with your redacted diagnostics.
At global scope, AgentKit merges only its owned registrations into the shared
~/.codex/hooks.json, preserves foreign or user structures, and removes empty
AgentKit-owned structures when the last owner leaves. Do not hand-edit ownership
sidecars or broadly delete the shared hooks file.
Check configuration scope
From the same project directory as the runtime session, run:
ak config prefs resolve
ak config prefs validateThe project file overrides user preferences. A disabled hook preference can change hook behavior, but it does not install a missing Skill or Agent. See Configuration problems before editing a file.
After changing hook state storage or reinstalling hook registrations, restart active Claude Code and Codex sessions before testing. Existing sessions can retain the earlier hook inventory and state paths.
Verify the result
The issue is resolved when the adapter-specific doctor report is healthy, any applicable audit is clean, and a new runtime session in the intended scope lists or recognizes the expected item. If those checks pass but discovery still fails, export a redacted bundle:
ak diagnostics export --json > agentkit-diagnostics.jsonRecord the Kit, target, scope, selected Skills, and runtime version with the report.