You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The model catalog of the family openai (lib/providers/catalogs/openai.json), the table a runtime of that family names with models.catalog: the tiers fast gpt-6-luna, balanced gpt-6.1-terra, deep gpt-6.1-sol and frontier gpt-6-astra (ids of the pattern ^gpt-[a-z0-9.-]+$, passed as ids, with no alias), and the effort levels low to max under the same names. No tier is verified yet (verified_on is null until a real run uses it); the vendor's sixth effort level, ultra, has no qargi level and is not mapped.
The local runtime codex (lib/providers/codex.json, data only, no code of its own): a project whose local provider is codex runs its members with qargi local run, which starts codex exec --json --ephemeral --ignore-rules --strict-config -C CLONE [-m MODEL] [-c model_reasoning_effort=EFFORT] -o FINAL in the run's clone with the prompt on standard input, adding --sandbox workspace-write --add-dir OUT --add-dir CLONE/.git for a write run and --sandbox read-only for a read-only one (--dry-run prints it). The clone's .git is added because workspace-write keeps it read-only, so git add failed on index.lock and a build member could not commit (a live check with codex-cli 0.167.1 showed git add and git commit working with it). The cost of that grant: a write member can change its own clone's git configuration and hooks. The clone's only remote is the run's own bare copy, with its push URL disabled, the sandbox has no network, the lead takes the work from the patches in OUT, and qargi local verify compares the real repository's refs; a read-only run never gets the grant. A path of the run in a definition's argv ({clone}, {out_dir}, {run_dir}, alone or with a path after it, such as {clone}/.git) must stay inside its directory and pass through no link, or qargi local run refuses the run: a .git an earlier member left as a link would otherwise point the sandbox's writable directory anywhere. The read-only barrier is that sandbox alone (barrier.kindsandbox-args, claimed partial): it holds a member's shell commands, not its reads, and no guard hook runs. Headless dispatch, the read-only barrier (partial) and the token report are verified by live checks with codex-cli 0.167.1 on 2026-11-11 (verified_on and source in the definition name the evidence), so a review role on codex runs with the barrier's note and needs no provider accept; the model and effort overrides (accepted in a run, but no event names the model or effort used), skills and MCP stay unverified and count as not supported. The member's last message goes to a new file of the run (FINAL, below) and becomes OUT/report.md, and the run's contract addenda (lib/providers/codex/local-run.md) say so. --ignore-rules keeps every Codex execpolicy rules file out of a run (a rule can let a command run outside the sandbox), and --strict-config makes Codex refuse a key of the run's configuration file it does not know, so a baseline key a later CLI renames stops the run instead of being ignored. A Codex member gets the MCP tools of its role and the runtime's baseline in the configuration file of its run home (below), and no resumed session. It gets no qargi skill: its CODEX_HOME and HOME are the run home, which has no skills directory, its clone carries only the skills the repository commits under .agents/skills (a session's untracked links do not travel to a clone), and the baseline turns Codex's bundled skills off, so a member receives the contract and the task, and never a lead-management skill (a test runs a member with qargi-flow, qargi-verify and qargi-task linked where a Codex lead finds them and checks that it sees none). qargi provider notes answers spawn, session-model, exploration, skills-dir, identity and commands for it.
A command runtime is told where to write the member's last message with the placeholder {final_message}: a file in a directory of the run that qargi local run makes new for each run (RUN/final.XXXXXXXXXXXX/message.md, mode 700), never a file of OUT, so the runtime never writes into OUT itself. When the process has ended the file is taken only as a regular file with one name, of UTF-8 text, at most 1 MiB, opened without following a link or waiting on a pipe; it is published as OUT/report.md by renaming a new file (mode 644) over that name, so a link, a pipe or a second name a member left there is replaced and never written through. A link, a pipe or a second name at the private file is removed (what it points to is untouched), a directory there is left, and a file that is too large or not text is kept for you to read; none of them is published. The output says what became of it (REPORT=OUT/report.md (N bytes ...) or REPORT=none: WHY), and RUN/dispatch.json records it (report: state, why, bytes, kept, previous). On --again the report of the earlier run is set aside as OUT/report.md.previous just before the member starts: a run that publishes a report replaces it, or one an earlier rerun set aside (PREVIOUS_REPORT=replaced), and a run that publishes none, a failed or refused one included, leaves it there (PREVIOUS_REPORT=kept as ...), where neither review check nor local verify takes it for this run's report. A report.md that is not a plain file of its own (a link, a pipe, a directory, a second name) refuses the run before anything starts. --dry-run prints FINAL_MESSAGE=. The codex runtime passes it as -o {final_message} in place of -o OUT/report.md, which let the vendor CLI write through whatever an earlier member had left at that name. The codex stub of the conformance suite now writes a last message where -o says, as the CLI does.
A read-only run whose report is the runtime's last message ({final_message}, the codex runtime's -o) gets its manifest from the lead: qargi local run writes OUT/manifest.json in the minimal report-only format of qargi review save (status, base, commits: [], the report in artifacts) with a run object of what the lead recorded (the run's id, role, runtime, class, the model and effort qargi passed, start, seconds, exit, outcome and packaged_by), taken from the lead's registry and from RUN/refs.before as read before the member started, never from the member. A Codex reviewer, which may write nothing, OUT included, had a report and no manifest, so qargi review check failed every one of its runs. The manifest is written only when the run's outcome is ok, its report was published and OUT holds no patch; otherwise MANIFEST=none: WHY says why, and a missing report, a report without a Findings heading or a valid last verdict line, and patches in a read-only OUT fail review check and local verify as before. It claims no test and no verdict (done.exit_code null, no gates); its status is BLOCKED when the first line of the report says BLOCKED, also under Markdown marks or as Status: BLOCKED (**BLOCKED**, # BLOCKED, **Status:** BLOCKED). The manifest of an earlier run is set aside as OUT/manifest.json.previous with the report (PREVIOUS_MANIFEST=), and a manifest.json there that is not a plain file of its own refuses a read-only run before anything starts. A write run's manifest stays the member's. RUN/dispatch.json records manifest (state, why, previous). The Codex addenda and the providers page say so.
A runtime started by qargi local run can have a home directory of its own (dispatch.home in lib/providers/schema-2.json: {env, dir, link: [{from, to}]}): the member gets RUN/home/DIR in the variable env, and each file from of your home is linked into it as to when the run starts and unlinked when the run ends, also when it fails or times out. The file is never copied; --dry-run prints HOME_ENV=, HOME_DIR= and HOME_LINKS= with the link names only, and dispatch.json records the names, never a source path or a value. A source that does not exist is not linked (a note says so). What the runtime does to the link during the run (a sign-in it refreshes) loses nothing, and qargi never writes the source: written through the link, it lands in the source, which qargi cannot prevent (a note); the link deleted, the source is untouched (a note); the link replaced by a file of its own (an atomic replace), that file is kept as NAME.from-run (mode 600) in the run home, never written over the source (another run, a session of the runtime or a sign-in of yours may have written it meanwhile), named in a HOME_RESIDUE= line and in home.residue of dispatch.json, with a note that says whether the source is still the file it was when the run started (the same real path and the same sha256, taken in memory then and never printed or recorded); you reconcile it yourself (docs/members-and-providers/codex.md says how), qargi local list and verify name it and qargi local clean removes it. No note or record holds a value. A variable of the run home (CODEX_HOME) set in your environment to another directory is a note, without its value: the run links the sources the definition names. The directory is made and the links removed without following a link a member may have put in the run directory. provider check, provider import and local run refuse a variable that qargi sets or never hands on (HOME, PATH, GIT_*, QARGI_*, XDG_*, the loader variables and the others env_pass refuses, and LANG, LC_ALL, TZ, TERM) or that env_pass also names, a dir outside the run home, a from that is not a plain path under your home or that lies in qargi's directory, a credential store of your other tools (ssh, gpg, git, forges, clouds, keyrings), a startup file of your shell (~/.bashrc, ~/.profile and their kin), what your desktop or service manager starts (~/.config/autostart, ~/.config/systemd, ~/.config/environment.d) or ~/.local/bin (checked again where the file really resolves when the run starts), a to that is not a plain file name, more than 8 links, an unknown key, and a run home on a runtime that is not a command runtime. The codex runtime uses it: CODEX_HOME is RUN/home/.codex with your ~/.codex/auth.json linked in, so a member keeps your Codex sign-in and plan, and its Codex loads nothing else of your Codex home (its settings, sessions and hook trust). This is configuration separation, not secrecy: the sandbox holds writes, not reads, so a member can still read the linked file and the rest of your ~/.codex (sessions, history) by path.
qargi packs apply --target codex PROJECT renders the tool packs of a project whose local runtime is codex into config.toml: one [mcp_servers.PACK] table per tool pack with its url and enabled_tools, the tools a member may call for the roles the pack reaches (the policy of the member tool lists: never an always_ask tool, and for a role of the read-only class only a declared read). A pack with no such tool gets no table, and the plan lists the tools of each table or says that the table is left out. Two tools Codex would name alike are refused as for Claude Code. The format is data: resources.mcp.formattoml is written by a small TOML writer (tables, texts, whole numbers, booleans and lists of texts, every text escaped; anything else is refused), and resources.mcp.tool_lists (allow, deny: JSON pointers into the server entry) in lib/providers/schema-2.json says where a runtime takes the tools of a server. provider check refuses tool lists that are not pointers, that land on a key the entry template sets, or that come without a permission_rule naming {server} and {tool}, and an entry template that TOML cannot hold. codex claims mcp (yes, not yet verified) and has the render target codex and no launch line: apply prints launch: none instead of failing. The render needs the skills claim of codex verified, as every render does, so until then apply exits 3.
qargi local run records the tokens a command runtime reports on its standard output: a definition's dispatch.output.usage (the keys of the transcript usage rule, select, skip, tokens, fields and model, now one node usage of lib/providers/schema-2.json that both use) picks the JSON lines of OUT/transcript that report a turn's usage, and when the run ends each field is added up over them into RUN/dispatch.json (usage: events, tokens per field, and model when the rule names it) and printed as USAGE=input_tokens=N ... (K events), or USAGE=none when no line matched. Only whole numbers count; a line that is not JSON is passed over. A field that no matched line reports is not recorded as 0: it is left out of tokens, named in unreported and on the USAGE= line (not reported, so not counted: ...), since absent is not zero. provider check and local run refuse a rule on an output that is not jsonl, a rule without tokens or fields, a key that is not a JSON pointer where one is needed, and an unknown key. The codex runtime adds up the usage of its turn.completed events (input, cached input, cache write, output and reasoning output tokens) and claims cost_reportpartial: tokens only, since a ChatGPT sign-in reports no money per run, and not verified until a real run.
A member started by qargi local run gets its own MCP file when its runtime declares dispatch.run_config ({in, file} in lib/providers/schema-2.json): when the run starts, the file is rendered from the runtime's resources.mcp for the run's role, as the lead's registry records it (an ability file rewritten in the run directory changes nothing), and the run's class: each server lists the tools a member may call (never an always_ask tool, under the read-only class only a declared read), and a pack with none gets no server. It goes into the run home (in: home) or RUN/config (in: run), mode 600, never through a link a member may have put there; the new placeholder {run_config} is its path for a runtime that takes it by a flag, and has no value when no tool pack reaches the role: then nothing is written, and a file of that name left there is removed. --dry-run prints RUN_CONFIG= (the path, or none with the reason) and RUN_CONFIG_TOOLS= (the tool names), and dispatch.json records the path, the role and the tool names; the servers' addresses are printed nowhere and no vault value is read. provider check refuses it on a runtime that is not a command runtime, in the home without dispatch.home, under the name of a link of the run home, and without resources.mcp.tool_lists. A definition can give the file a baseline (dispatch.run_config.baseline): settings of the runtime's own configuration, written at the root of every run's file whatever tools reach the role, so a run with no MCP server and a run with one get the same settings; with one the file is written for every run, --dry-run prints RUN_CONFIG_BASELINE= and dispatch.json records it in run_config.baseline. provider check refuses a baseline that is empty, holds an empty object or a value the file's writer does not take, or sets anything at or below resources.mcp.root_pointer, which only the tool packs fill. The codex runtime uses it: a member's MCP tools and its baseline are the config.toml of its CODEX_HOME in the run home, the user-level configuration of its Codex, so codex exec gets no --ignore-user-config, which would drop that file too (your own Codex configuration stays out of the run, because CODEX_HOME is the run's). The baseline sets approval_policynever, under workspace-write no shell network and no /tmp (the run's TMPDIR stays writable), hosted web search disabled, the features apps, plugins, remote_plugin, hooks, computer_use, browser_use, in_app_browser, image_generation, tool_suggest and skill_mcp_dependency_install off, and the bundled skills off; it holds no trust entry, so the clone's own .codex/ (its configuration, MCP servers, rules and hooks) is not loaded, while its AGENTS.md is. codex-cli 0.167.1 reads each key (seen offline: a value of the wrong type is refused naming the key, the features list shows them off, the prompt input says the approval policy is never and lists no bundled skill, and codex sandbox with those keys refuses /tmp and the network); that each holds in a real run is not yet verified, and a system-wide or managed Codex configuration is not excluded.
qargi provider check has a case for the barrier kind sandbox-args, barrier-sandbox-args: the argv qargi local run builds for a read-only run must carry the definition's read-only arguments (its class_argv and {"class": "read-only"} groups), set their flags nowhere else in the argv, where they could be overridden, and carry no flag with its value of the write class's arguments, a write grant such as --add-dir CLONE/.git (conformance case 11 is the same case). The case can only hold read_only_barrier back: when it fails the capability stays unverified, and when it passes it verifies nothing, because it shows what qargi passes and not that the runtime's sandbox holds, which is still recorded with qargi provider attest.
The conformance suite (bash tests/conformance.sh NAME, lib/conformance/run.sh) checks a command runtime, one whose dispatch.mode is command, which it used to skip when the runtime had no adapter. qargi local run starts the runtime's stub (tests/providers/NAME/stub, or --stub DIR) in place of the command: case 11 is the sandbox-args case of provider check; case 12 makes a write run and a read-only run and checks that the stub gets the argv RUN/dispatch.json records, the prompt with the task block and the class, the arguments of its own class and none of the other's, that OUT/transcript is what it printed, and that the usage rule adds up a usage from it; case 13 checks the command's environment: its own HOME, no variable of yours that env_pass does not name, and the run home's variable and links while it runs, with the linked file's content and source path in no output or record; case 14, for a runtime with a dispatch.run_config.baseline, checks that a write run and a read-only run each get the configuration file holding the baseline and nothing else, found by the command in its run home while it runs and recorded in RUN/dispatch.json. The adapter cases 1 to 10 are left out, with one line, for a runtime with no adapter. codex has its stub, which replays the JSON lines of a codex exec --json run with two turn.completed usages, and bash tests/conformance.sh codex is a step of the suite.
The review of a provider pack (qargi provider import, seal and enable) shows the runtime's run home: the variable it is named by, its directory under the run's home, and each file of your home it links into every run, as the definition names it (run home (dispatch.home): CODEX_HOME is RUN/home/.codex; files of your home linked into it for each run: ~/.codex/auth.json as auth.json). It names the files only; it never reads them or shows where they resolve.
The qargi-providers skill says how a runtime held by sandbox-args is checked live (verify.md): its barrier with the runtime's own sandbox command and no model call (for codex, codex sandbox, at no cost), one smoke run on the fast tier at low effort for the sign-in through the run home's link, the report file and the tokens (a model or effort override is verified only when an event names what was used), and, before members rely on it, a sign-in rewritten through the link, the MCP tool names, enabled_tools hiding a server's other tools and commits under workspace-write with the clone's .git added; a shipped runtime records each result as verified_on and source in its definition, and what the shipped codex has verified and what not. Its definition page names dispatch.home, dispatch.run_config, dispatch.output.usage and resources.mcp.tool_lists.
The addenda of a Codex run (lib/providers/codex/local-run.md) tell the member that its MCP tools are the ones its run's configuration lists, and no others. The providers page has a table of what the codex runtime is and is not (its barrier the operating-system sandbox, claimed partial; MCP held by enabled_tools; no guard hook; sign-in by a link; tokens only; one local runtime per project, so no mixed runtimes), and the models page its catalog openai.
qargi local run ends a run cleanly however it ends, and says how. It writes RUN/dispatch.json when the run starts (outcomerunning, the process ids of the runner and, once started, of the member, and the run home's links) and again at the end, so an earlier run's outcome never stays: a command that cannot be started is transport (exit 4) and a run home, MCP file or transcript that cannot be made is refused, each with its error. SIGINT, SIGTERM and SIGHUP to the runner stop the member's process group (TERM to the group, which is then watched, not only the member, for up to 5 seconds, so a child that ignores TERM after the member ended on it is not missed; then KILL for what is left, watched the same way), remove the run home's links and record interrupted with the signal and group_left, the number of the group's processes still alive (exit 128+N); the output says the group was stopped only when none of it is alive, and otherwise how many of its processes survived (the same for a run past its bound). A process that moved to a process group of its own, and one left running after the member ended by itself, are not stopped; one that comes after the member ended is only noted, and a signal the runner was started with ignored (nohup) stays ignored. SIGKILL cannot be caught, so the start record stays: the next start refuses while that runner or its member still runs (naming the member's process group to stop; the runner is told by the run's real path, also when it was started by a relative one from another directory) and otherwise needs --again, which replaces the links left in the run home and removes stale last-message directories; qargi local list (a residue: line under the run) and qargi local verify (a note) name the links left, and qargi local clean removes the run with them and says so. A run home the member moved or replaced is searched for the links qargi made, which are removed where found; a link not found is named, never said to be gone.
The documentation page Codex as lead and as member (docs/members-and-providers/codex.md): what is verified live, by what, on which CLI version and date, and what is not; the platform (qargi runs on Linux, where codex-cli's sandbox is bubblewrap; its macOS sandbox plays no part), what a member run loads and what it does not (your Codex configuration, the clone's untrusted .codex/, a system-wide configuration that is not excluded), the run baseline key by key, what a member can reach (files, TMPDIR, the shell's network against hosted search and MCP, git, no guard hook, the sign-in it can read), its skills and MCP tools (raw names in enabled_tools, mcp__ names for the model, the limits for an authenticated server), the output of a run (report overwrite on --again, the lead's manifest of a read-only run, refused uncommitted changes, token-only usage where an absent count is not zero), a Codex lead's setup (install.sh --user --runtime codex, what a Codex session lists, what is not verified), a complete build and review run from prepare --task-file --done to local clean, and sending a message to a Codex session with codex queue. qargi provider notes message gives a lead the codex queue line and says a queued message is never an approval. The providers, models, members, install and local-session pages and the qargi-providers skill say the same where they name Codex; the models page says that a catalog id is not model access and that the tier order is no benchmark.
A command runtime can declare the places its sandbox hides from the member (dispatch.hidden_paths in lib/providers/schema-2.json: prefixes, per class the run paths it shown anyway, and a note), and qargi local prepare and qargi local run refuse a run whose member would not see a path it works with (exit 2, before anything is made or started; a dry run too), naming each path (and its real path when a link leads there), the prefix and the fix: --scratch on another filesystem (a directory under your home, such as ~/.cache/qargi-runs; one under /tmp is not advised, since no check has shown a run there working), or QARGI_RUN_TMP for a hidden TMP. A read-only member works with CLONE, CONTRACT and GIT, a write member also with OUT and TMP; the task block reaches it in its prompt. codex declares /dev: its Linux sandbox mounts a /dev of its own, so a run under /dev/shm left a read-only member without its clone and contract and a write member without its contract, and nothing said so. A codex run with --scratch on disk works, its TMP on /dev/shm included (a write run's TMP is bound into its sandbox; a read-only member writes none). The conformance suite has a case for it (15).
qargi local run notes a change a member made to what git in its clone would run. A member that can write the clone's .git (the write class of codex adds it as a writable directory) can set a hook, core.fsmonitor, an alias or a filter driver there, which runs as you when you run git in that clone. For every run whose argv grants the clone's .git, and every run whose class gets no sandbox arguments from its runtime, the lead reads .git/config, .git/hooks/ and .git/info/ before the member starts (without following a link or running git there) and compares them when it ends: a configuration key added, changed or removed, other than what git branch sets (branch.NAME.remote, merge, rebase, description), and an entry of hooks/ or info/ added, removed or changed, are named in a GITDIR=changed: line and recorded in git_dir of RUN/dispatch.json (watched: granted or unsandboxed, and changed), by key and entry name, never a value. Nothing is restored. The line, the WORKTREE=uncommitted refusal and the qargi local verify message for a run that did not collect now say never to run git in a write member's clone: take the work from the patches in OUT, copy files out, or make a clean copy first with git clone --no-local, as git(1) advises under SECURITY. They said to take the change or the commits from the clone yourself.
Changed
qargi provider notes skills-dir for codex names ~/.agents/skills beside ~/.codex/skills and the install that links qargi's skills there, and says a member run loads only the skills its repository commits, where it said a member ignores the user's configuration. The documentation no longer says that a run's config.toml is the one configuration file a Codex member reads, or that an agent is given no way to push: the pages state what holds instead (a git without credentials, a remote with its push URL disabled, no network for a sandboxed member's commands, and qargi local verify comparing the real repository's refs).
The README says what qargi supports of an agent and a push (a git without credentials and a clone whose only remote is a copy with its push URL disabled, so an ordinary push has nothing to reach or authenticate with, and a check that the real repository's refs did not move), where it said an agent is given no way to push. Its quick start, and the members page, say that a project on codex has no qargi agent add and runs each task with qargi local prepare and qargi local run.
qargi help local and the manual page call a local run one whose git has no credentials (Prepare, verify, close, list and clean a local run, its git without credentials), where they said it has no way to push.
A write run that leaves a change to a tracked file uncommitted and returns no patches is a refusal, not a finished task. qargi local run ends such a run refused (exit 2) when its runtime ended ok and OUT holds no patch or bundle, prints WORKTREE=uncommitted: CLONE holds N changed tracked file(s) ... and records worktree (tracked, untracked, patches, refused) in RUN/dispatch.json; new files never added (untracked) alone are said (WORKTREE=untracked, which says they are not a refusal and are lost when the run is cleaned) and not refused, and qargi local clean warns when it removes a clone that holds what no commit has (new files or changes to tracked files), with their counts. qargi review check fails a run with no patches whose clone holds such a change unless its manifest says BLOCKED (then a note), with or without --allow-empty and also when OUT holds a report with Findings and a verdict; untracked files are a warning. The clone's state is read with git run so that nothing the member put in the clone's git configuration runs: no system or global configuration, the work tree named outright, no fsmonitor, every filter driver the clone names emptied, no optional locks.
The help of qargi local prepare and qargi local run and the manual page say that the runtime may refuse a run whose paths its sandbox hides from the member (dispatch.hidden_paths, /dev for codex), before anything is made or started, naming the path and the fix; the help of local run also names the GITDIR=changed: line and says never to run git in a clone whose .git the member could write.
The README and the documentation overview describe qargi as a CLI and a set of skills that any lead loads, where they called it a set of Claude Code skills: the lead is the agent session you work in, Claude Code and Codex are the leads and local runtimes qargi ships, and another runtime is defined as data. The quick start installs the skills for a Claude Code or a Codex lead (--runtime codex), starts a project on claude-code or on codex, and says that /qargi-task is Claude Code's slash command, which another lead replaces by loading the skill or running qargi local prepare and qargi local run; the install and flow pages name ~/.claude and /qargi-task as Claude Code's.
Fixed
The qargi-task skill loads in a Codex session: the argument-hint of its front matter, a double-quoted string followed by more text, was not YAML, and codex-cli 0.167.1 dropped the skill without a word. It is now one quoted string with the same text. tests/test_install.sh checks the front matter of every skill under skills/ with a strict rule (an unquoted value that starts with a YAML indicator or holds : or # fails, and so does text after a quoted value); qargi-packs, qargi-session, qargi-team and qargi-verify failed it too (a : in the description, or the argument-hint[NAME], which YAML reads as a list; codex-cli 0.167.1 listed them, a strict YAML parser did not read them), and each value is now one quoted string with the same text, so every skill passes the rule.
qargi local run starts the real program of a command runtime, never a version manager's wrapper. The command word is resolved on your PATH, entry by entry, to the first regular executable file whose real path has that name (or the name with an extension, a launcher such as codex.js, or with a suffix after a dash, a release binary such as codex-x86_64-unknown-linux-musl), and that absolute path runs: --dry-run prints it as COMMAND= (it printed the bare word) and RUN/dispatch.json records it as command. A wrapper or shim that is a link to a program of another name is passed over with a note; when nothing else is left the run is refused with exit 3, naming each entry passed over and why. A codex that was such a wrapper looked for Codex under the run's home, so the sandbox could not start it again and every shell command of the member failed. The member's own PATH is unchanged; a version manager's wrapper on it for another tool (go, node, python) also runs under the run's home, which the Codex page says, with the fix (the directories the tools are installed in first on PATH).
qargi packs apply --target TARGET PROJECT records the apply in the audit log as packs-apply-TARGET, the render target it applied (packs-apply-codex for a Codex project). Every render was logged as packs-apply-claude-code, whatever its target.
The review of a provider pack (qargi provider import, seal and enable) no longer lists the words of a definition's command line and notes as eval or exec constructs: the definition of codex had eight such flags, one for every codex exec in its argv and its notes. In definition.json an eval or exec is flagged only as code, a call (exec(...)), an eval or exec of an expansion ($VAR, $(...), a backquote) or the shell=True and os.system( forms; in the pack's scripts and other files it is flagged as before.
