pullfrog 0.1.56 → 0.1.59

package/dist/internal.js

@@ -531,6 +531,22 @@ var providers = {
       }
     }
   }),
+  azure: provider({
+    displayName: "Azure OpenAI",
+    // the resource name is half the endpoint URL and the deployment is the model
+    // id, so both are as load-bearing as the key. only the key is sensitive.
+    envVars: ["AZURE_API_KEY", "AZURE_RESOURCE_NAME", "AZURE_DEPLOYMENT"],
+    models: {
+      // single routing entry — the real model is the customer's deployment name,
+      // read from AZURE_DEPLOYMENT at run time. see ModelRouting docs for why
+      // Azure can't be cataloged even though models.dev lists it.
+      byok: {
+        displayName: "Azure OpenAI",
+        resolve: "azure",
+        routing: "azure"
+      }
+    }
+  }),
   "openai-compatible": provider({
     // "Custom" is the picker group, "OpenAI-compatible" the entry under it, so the
     // menu reads `Custom › OpenAI-compatible` and a second custom backend (a
@@ -878,6 +894,8 @@ function formatMcpToolRef(agentId, toolName) {
   switch (agentId) {
     case "claude":
       return `mcp__${pullfrogMcpName}__${toolName}`;
+    case "codex":
+      return `${pullfrogMcpName}__${toolName}`;
     case "opencode":
       return `${pullfrogMcpName}_${toolName}`;
     default:

package/dist/models.d.ts

@@ -20,8 +20,16 @@ import { type EffortPosition } from "./effort.ts";
  * routing slugs, not model aliases: the harness reads the backend-specific
  * env var and routes to claude-code for Anthropic IDs or opencode for
  * everything else.
+ *
+ * `"azure"` is the same shape for a different reason. models.dev DOES carry an
+ * Azure catalog, but the id it lists is sent to Azure as the DEPLOYMENT NAME,
+ * and a deployment is named by whoever created it — so cataloging `azure/gpt-5`
+ * would only work for customers who kept the portal's default name. the
+ * deployment comes from `AZURE_DEPLOYMENT` instead. unlike bedrock/vertex it
+ * resolves to a provider-PREFIXED specifier (`azure/<deployment>`), matching
+ * openai-compatible, because `azure` is a real opencode provider id.
  */
-export type ModelRouting = "bedrock" | "vertex" | "openai-compatible";
+export type ModelRouting = "bedrock" | "vertex" | "openai-compatible" | "azure";
 export interface ModelAlias {
     /** stable alias stored in DB, e.g. "anthropic/claude-opus" */
     slug: string;
@@ -115,6 +123,7 @@ export declare const providers: {
     "opencode-go": ProviderConfig;
     bedrock: ProviderConfig;
     vertex: ProviderConfig;
+    azure: ProviderConfig;
     "openai-compatible": ProviderConfig;
     openrouter: ProviderConfig;
 };
@@ -283,6 +292,38 @@ export declare function getAutoSelectHintModel(): string;
 export declare const BEDROCK_MODEL_ID_ENV = "BEDROCK_MODEL_ID";
 /** env var that supplies the Vertex AI model ID for the `vertex/byok` slug. */
 export declare const VERTEX_MODEL_ID_ENV = "VERTEX_MODEL_ID";
+/** provider key + slug prefix for the Azure OpenAI BYOK backend. matches opencode's own provider id. */
+export declare const AZURE_PROVIDER = "azure";
+/** resource name in the endpoint `https://<name>.openai.azure.com` — plain config, not a credential. */
+export declare const AZURE_RESOURCE_NAME_ENV = "AZURE_RESOURCE_NAME";
+/** API key for the Azure OpenAI resource — the one sensitive value. */
+export declare const AZURE_API_KEY_ENV = "AZURE_API_KEY";
+/**
+ * the customer's Azure deployment name, supplied for the `azure/byok` slug.
+ * Azure takes the deployment name where every other provider takes a model id
+ * (`@ai-sdk/azure` types the argument `deploymentId`), and the name is whatever
+ * its creator typed — which is why Azure gets a routing slug instead of the
+ * catalog entries models.dev publishes for it.
+ */
+export declare const AZURE_DEPLOYMENT_ENV = "AZURE_DEPLOYMENT";
+/**
+ * context-window size of the model behind the deployment. required for the same
+ * reason as its `OPENAI_COMPATIBLE_*` twin: opencode holds no metadata for a
+ * deployment name, and an undeclared limit both caps completions at 32000 and
+ * disables auto-compaction. see `azureProvider()` in agents/opencodeShared.ts.
+ */
+export declare const AZURE_CONTEXT_ENV = "AZURE_CONTEXT";
+/** max completion tokens the model behind the deployment accepts. required. */
+export declare const AZURE_MAX_OUTPUT_ENV = "AZURE_MAX_OUTPUT";
+/**
+ * opt this deployment into Chat Completions. opencode's azure loader calls
+ * `sdk.responses(modelID)` unless its `useCompletionUrls` option is set
+ * (`selectAzureLanguageModel`), so a deployment serving a model that predates
+ * Azure's Responses API — gpt-4, gpt-35-turbo — fails on the wire dialect
+ * rather than on anything we control. optional, and the only value here that
+ * isn't required.
+ */
+export declare const AZURE_USE_CHAT_COMPLETIONS_ENV = "AZURE_USE_CHAT_COMPLETIONS";
 /** provider key + slug prefix for the generic OpenAI-compatible BYOK backend. */
 export declare const OPENAI_COMPATIBLE_PROVIDER = "openai-compatible";
 /** base URL of the user's OpenAI-compatible endpoint (e.g. a Cloudflare AI Gateway URL). */

package/dist/utils/agent.d.ts

@@ -19,4 +19,14 @@ export declare function resolveModel(ctx: {
 }): string | undefined;
 export declare function resolveAgent(ctx: {
     model?: string | undefined;
+    /** set on router / OSS runs, where the model is served by OpenRouter. those
+     * pin no `model`, so without this the auto-select branches below would read
+     * a stored Anthropic or OpenAI credential as the routing signal for a run
+     * that isn't using it. */
+    proxyModel?: string | undefined;
+    /** the account opted in to the EXPERIMENTAL codex harness, already ANDed
+     * server-side with the global kill switch. false — the default for every
+     * account — routes OpenAI models to opencode exactly as before the harness
+     * existed. see wiki/codex-agent.md. */
+    codexAgent?: boolean | undefined;
 }): Agent;

package/dist/utils/codexHome.d.ts

@@ -17,6 +17,12 @@ export interface InstalledCodexAuth {
      * OpenCode refreshed during the session (only happens on long runs
      * that span >50min — see wiki/codex-auth.md "Concurrency"). */
     originalRefresh: string;
+    /** id_token from the env at materialization time. OpenCode's auth file has
+     * no slot for it, so the post-hook has to re-attach this one or the written
+     * back blob loses it — and the Codex CLI REFUSES an auth.json without
+     * `tokens.id_token` (measured: `missing field 'id_token'`), so dropping it
+     * silently disqualifies the account from the codex harness forever. */
+    originalIdToken: string | undefined;
 }
 /** materialize CODEX_AUTH_JSON from env into a disk path OpenCode reads from.
  * returns null when the env var is absent, malformed, or wrong auth mode —
@@ -27,3 +33,24 @@ export interface InstalledCodexAuth {
  * `process.env.XDG_DATA_HOME` so every opencode subprocess discovers the
  * auth.json; no refresh, no DB interaction. */
 export declare function installCodexAuth(): InstalledCodexAuth | null;
+export interface InstalledCodexHome {
+    /** value to set as CODEX_HOME for the codex subprocess. holds auth.json,
+     * config.toml and the session rollouts the resume path reads. */
+    codexHome: string;
+    /** absolute path of the auth.json we wrote. the codex CLI rewrites this file
+     * in place when it refreshes, so the post-hook diffs it for a rotation. */
+    authPath: string;
+    originalRefresh: string;
+}
+/**
+ * materialize CODEX_AUTH_JSON into a CODEX_HOME the codex CLI reads directly.
+ * unlike {@link installCodexAuth} there is no shape conversion — the stored
+ * blob IS the codex CLI's own `auth.json`, so it round-trips verbatim.
+ *
+ * returns null when the env var is absent, malformed, or carries no
+ * `tokens.id_token`. that last one is not defensive: the CLI's `TokenData`
+ * makes `id_token` a required field with a JWT deserializer, so an auth.json
+ * without it fails to load with `missing field 'id_token'` before any model
+ * call. callers treat null as "codex CLI can't use this credential".
+ */
+export declare function installCodexHome(): InstalledCodexHome | null;

package/dist/utils/roleMirror.d.ts

@@ -17,6 +17,20 @@ import type { GitHubAppPermissions } from "./github.ts";
  * permissions have no object granularity — so those runs get no token and use
  * the object-scoped MCP tools instead.
  *
+ * `role` is the triggerer's EFFECTIVE permission on THIS repo, and where it
+ * came from is deliberately not asked. `getCollaboratorPermissionLevel` already
+ * folds direct grants, team grants and the org base permission into one answer,
+ * so an org member who is `write` org-wide and a user with a single direct
+ * grant resolve identically — which is correct, because on this repo they can
+ * do the same things. Nothing in the action queries org membership.
+ *
+ * The token is then scoped to the current repo UNCONDITIONALLY: `resolveTokens`
+ * passes no `repos`, and `acquireTokenViaOIDC` always appends
+ * `$GITHUB_REPOSITORY`, so the list is exactly `[this repo]` even when the
+ * triggerer holds org-wide admin over hundreds. That asymmetry is deliberate
+ * margin — the invariant is "never MORE than the user has", and one repo out of
+ * many satisfies it with room to spare.
+ *
  * The set is a strict SUBSET of what any qualifying role holds, so the mirror
  * is one-directional by construction — it can never over-grant:
  *

package/dist/utils/runContext.d.ts

@@ -33,6 +33,7 @@ export interface RepoSettings {
     shell: ShellPermission;
     prApproveEnabled: boolean;
     autoMergeEnabled: boolean;
+    codexAgent: boolean;
     signedCommits: boolean;
     repoIntelligence: boolean;
     progressComments: boolean;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "pullfrog",
-  "version": "0.1.56",
+  "version": "0.1.59",
   "type": "module",
   "bin": {
     "pullfrog": "dist/cli.mjs",
@@ -32,6 +32,8 @@
     "@clack/prompts": "^1.2.0",
     "@modelcontextprotocol/sdk": "^1.26.0",
     "@opencode-ai/sdk": "1.18.5",
+    "@openai/codex": "0.147.0",
+    "@openai/codex-sdk": "0.147.0",
     "@octokit/plugin-throttling": "^11.0.3",
     "@octokit/rest": "^22.0.0",
     "@octokit/webhooks-types": "^7.6.1",