Share organization developer policy

Last updated: 2026-10-28

The next prompt started after an administrator finishes publishing checks the latest development guidance and supplies it to Claude. This works within the same conversation: a policy update does not require restarting the conversation or invoking a particular skill. Saving a draft alone does not publish it.

Guarantees and limits

The server's published organization policy is authoritative, not a distributed local POLICY.md or another repository instruction file.

• Every prompt checks the server and supplies the current development text again. A cached body or last-emitted revision never skips that check or delivery.
• Withdrawal is supplied explicitly to replace earlier guidance. The next prompt also checks after resume, clear, or compact.
• Supplying context does not prove AI compliance or receipt (ACK). The last-checked and last-emitted revisions in status are diagnostic, not proof that a model read or followed the policy.
• This is not DLP (data loss prevention). It checks policy freshness and supplies LLM context; it does not detect or remove secrets or personal information from prompts, or block their external transmission.
• This does not interrupt an ongoing response or tool, rewrite existing code, or retract previous conversation text.
• This is not server-side security enforcement. Existing deployment permissions, approvals, platform checks, and user confirmation still apply. If repository instructions conflict with organization guidance, ask the responsible person rather than silently discarding either.

Host support

The 2.1.312 host observations cover context, blocking, missing CLI, timeout, resume, clear, and compact. They are not proof of every installed end-to-end combination, model compliance, or measured latency. Check help and release information for both CLI and plugin to ensure the installed releases contain this feature.

Administrators: save and publish

Open the organization's Settings → Developer policy tab (?tab=developer-policy). Active organization administrators (tenant_admin) and platform administrators can manage drafts, publishing, and history. Settings or apps sub-administrator permissions alone do not grant this access. Members can read only the current published policy.

1. Confirm the organization and disclosure scope. Each organization has one policy, without per-app inheritance.
2. Write Development guidance and Deployment guidance. Each section allows 4096 UTF-8 bytes, not characters; non-ASCII text and emoji may use several bytes. Either section may be empty.
3. Switch between edit and preview, then save the draft. This is separate from saving general settings. Drafts are not yet supplied to members or AI.
4. In the publish dialog, review the persisted text. Confirm on every publication that the policy may be sent to the AI services users connect. This acknowledgment is not provider approval or an AI delivery ACK. Never include secrets or personal information.
5. Finish publishing to create a new revision. The next prompt started afterward in a bound project receives development guidance. Deployment guidance is read separately during deployment preparation.

Preview, publish dialog, and history use safe Markdown: raw HTML and dangerous link schemes do not execute, and external images are not fetched automatically.

To withdraw, clear both sections to exactly empty strings, save, and publish. Whitespace-only text is not withdrawal. Withdrawal still requires acknowledgment and creates a new positive revision; it does not delete history. Never-published policy is unset (revision 0), published policy is published, and withdrawn policy is withdrawn.

If another administrator changes the policy first, a conflict (409) requires comparing your edits with the server draft and merging manually. Do not blindly overwrite or discard local input. Publishing the same text again also requires explicitly saving a draft against the newest published revision first.

If a save or publish response is lost, do not assume failure or immediately retry. Recheck the server draft, current policy, and publication history for the attempted draft. A later change may leave the result unknown. History is available newest revision first.

On the first 401, the policy editor locks while retaining local text; it does not automatically refresh authentication. Recover your login outside the blocked editor, then return and compare the server draft before saving again.

Existing private deployment review-guidelines and the plugin's own POLICY.md remain separate. Their contents are not automatically migrated or made public.

Members: bind a project

Replace the UUID and path with your actual organization and project:

axhub tenants developer-policy get --tenant <uuid> --json
axhub tenants developer-policy bind --tenant <uuid> --project <path>
axhub tenants developer-policy status --project <path> --json
axhub tenants developer-policy unbind --project <path>

• get makes an authenticated current server read. It is not a hook test or proof of AI delivery. Use it for manual retrieval in Codex too.
• bind checks organization access, then stores origin, tenant, and schema in local .axhub/state/developer-policy.json, without credentials. Replacing a different binding requires explicit --force after checking the intended target.
• The nearest explicit binding applies without crossing a Git repository or worktree boundary. Bind each worktree separately. A manifest's app name/slug or cached organization selection is not binding evidence.
• The HTTP destination comes from trusted CLI profile/endpoint settings. A binding's origin is only an equality check, never a source for redirecting credentials.
• status is offline diagnostics: it distinguishes profile, binding source marker (not an absolute path), all disabled reasons, capability, last check, and last-emitted revision. AI delivery ACK is unavailable.
• bind, unbind, and status default --project to the current directory. unbind removes only the local binding, not the server's published policy. An unreadable or damaged binding blocks rather than pretending the project is unbound.

Disable automatic sync

Automatic sync is disabled if either condition holds (OR):

• The host process has AXHUB_NO_POLICY_SYNC set to exactly 1.
• ~/.axhub/config/no-policy-sync exists.

Inspect all disabled reasons with status. To re-enable, remove both conditions and ensure the host uses the changed environment. Disabling sync or unbinding removes the next-prompt guarantee.

Explicit get and deployment preparation still read policy. This setting disables automatic hooks, not server permissions or deployment checks. With no CLI, the wrapper skips only when its process cwd is clearly unbound. An old CLI's final usage exit 64 likewise skips silently only for a clearly unbound process cwd; a bound project blocks as UNSUPPORTED. An old CLI cannot validate a differing host payload cwd. This is not a general fail-open rule: a supported helper validates payload cwd even when process cwd is unbound, and other failures or uncertain bindings block.

Deployment guidance

Deployment preparation identifies the actual target app's organization and reads current deployment_markdown through the authenticated CLI. Failure stops client-side preparation. unset and withdrawn allow normal preparation. An unsupported API on an old server is not treated as an absent policy.

A natural-language check against deployment guidance is not server enforcement. Existing platform context, permissions, approvals, and user confirmation remain. Ordinary development prompts receive only development guidance, not the deployment section.

Recover a blocked prompt

Blocking is neither a queue nor automatic resumption. Repair outside the chat in a terminal → verify an explicit read in the same environment → manually resend the prompt. Automatic preservation or restoration of the host's input is not promised.

Network errors and 429 responses have no automatic retry. OAuth refresh is limited to one attempt, and a 304 without usable cache allows at most one recovery GET, all within the shared deadline. The wrapper's two-second ceiling is a failure-handling bound, not measured latency or a successful-fetch SLA.

POLICY_AUTH_REQUIRED — repair authentication

Hooks never open a login window or keychain approval dialog. Match the host's profile, endpoint, and credential backend in your terminal. A successful axhub auth login --force stored only in the keychain does not prove that a file-backed, non-interactive hook can authenticate.

For profile-based file credentials, run axhub --no-keychain auth login --force, preserving the same profile and endpoint. This changes credential storage from the OS keychain to files. Check the location and permissions, and never paste files or tokens into chat or logs. If the host uses an explicit --token-file, repair that same file; do not assume profile-store login updates it. See CLI authentication options. Verify get in the same non-interactive environment, then resend the prompt.

Renew or replace an explicit token file through the workflow that originally issued it. Do not assume there is a CLI token-export command. Removing the file flag or switching to profile storage changes the credential source and must be an intentional user choice.

ACCESS_DENIED — organization access

Check the bound organization and signed-in identity; ask an administrator to confirm membership. Cache cannot bypass revoked access. Explicitly rebind if a different organization was intended.

BINDING_CONFLICT — inconsistent binding

Use offline status to inspect the binding source marker and trusted profile; check your endpoint configuration separately. The marker is not an absolute filesystem path. Do not fix an origin mismatch or damaged binding by inserting an arbitrary server address. Bind the intended organization, using --force only for an intentional replacement.

NETWORK — connection failure

Restore server reachability, VPN, or network access, then check explicit get. There is no stale-cache continuation or repeated automatic retry.

DEADLINE — freshness check timed out

Check network and non-interactive credential-store access. The blocked prompt will not automatically wait for a slow request or resume afterward.

CACHE_UNUSABLE — unusable cache

Check permissions and disk health for the storage location reported by the CLI. Do not copy policy text or credentials into cache by hand; recover through a server read.

UNSUPPORTED — unsupported combination

Use a compatible server, CLI, plugin, and host. An old CLI's usage error (64) or an old server's 404 does not mean no policy exists. Codex supports manual retrieval only.

PROTOCOL — invalid response

Align supported CLI/plugin releases. The helper must emit exactly one JSON object; extra stdout or malformed JSON is not success. Share sanitized error codes, not raw responses or policy text.

INTERNAL — internal error

Contact support with the sanitized error code and CLI/plugin/host versions. Optional error.context contains only known, validated profile, tenant_id, the fixed binding_source marker project:.axhub/state/developer-policy.json, and request_id actually received from the server's X-Request-ID; unavailable values are omitted. The adapter displays fixed recovery text and these safe diagnostics, not raw upstream prose. Copy only those diagnostics, never policy text, prompts, raw responses, absolute paths, tokens, or credential-bearing URLs. They are not host delivery ACKs.

RATE_LIMITED — request limit

Wait for the server's restriction to clear, then explicitly check again. Avoid retry storms and manually resend the prompt after recovery.