Founding member access recorded.
Checkout cancelled.

Signals · Codex profile

Codex

Every signal accepted for Codex. Each links to the run that produced it. The Codex profile carries the current evergreen state.

June 2026

  1. 2026-06-03 · Codex

    CLI 0.136.0 adds API-key registration for approved remote exec-server hosts

    • An operator running remote execution can register approved hosts via API key instead of entering credentials per session, changing the remote-exec authentication model.
    • This shifts trust to a pre-registered host allowlist keyed by API key — operators must decide which hosts are 'approved' and how those keys are scoped and rotated before enabling remote exec.
    • Verification path: upgrade to 0.136.0, register a test host, confirm only approved hosts authenticate and that key scope/rotation behaves as expected before exposing remote execution.
  2. 2026-06-03 · Codex

    Amazon Bedrock integration runs Codex models under AWS-managed authentication and billing

    • An operator with AWS infrastructure can now run OpenAI models through Amazon Bedrock, moving authentication and billing under AWS IAM and cost allocation instead of an external OpenAI API path.
    • This reframes where the trust and identity boundary sits — Codex model calls become AWS-native, which changes compliance and credential-management decisions for AWS-policy organizations.
    • Verification path: provision Codex models via Bedrock, confirm IAM scoping and that no model traffic leaves the AWS-managed path before treating it as compliance-satisfying.
  3. 2026-06-03 · Codex

    ChatGPT iOS 1.2026.146 adds optional Face ID / passcode lock for Codex

    • An operator running Codex on iOS can now require Face ID or a passcode to open Codex, adding a device-level authority gate that did not exist before.
    • It is optional, so the operator decision is whether to enable it as policy for mobile-deployed Codex access.
    • Verification path: update to 1.2026.146, enable the lock, confirm Codex requires biometric/passcode on foreground before trusting mobile as an access surface.
  4. 2026-06-03 · Codex

    Sites plugin (preview) adds in-app website and web-app creation and deployment

    • An operator can now create, deploy, and manage websites, dashboards, and web apps directly within Codex, removing the external-tool step for web deployment.
    • ChatGPT Business workspaces include Sites by default, so the operator decision is whether to allow/govern an in-product deploy surface that may already be enabled.
    • Verification path: confirm whether Sites is enabled in your Business workspace and whether agent-initiated deployments fit your hosting/governance policy before relying on it.

May 2026

  1. 2026-05-27 · Codex

    Goal mode graduates default-on; remote computer use after lock ships

    • Operators using Codex must decide whether goal mode is permitted as a baseline or constrained via permission profiles — the inheritance + managed-requirements features are the right tool for this.
    • Evaluators of remote computer use after Mac lock should treat the locked-host surface as a new authority decision, not a default; short-lived authorization and relock-on-input are sensible defaults, but the policy for which tasks may operate against a locked host is still an operator choice.
    • Plugin-marketplace evaluators (ChatGPT Business; Enterprise coming soon) should treat plugin distribution-by-marketplace as a new supply-chain surface to govern.
  2. 2026-05-27 · Codex

    Permission profiles get inheritance and an org-managed enforcement file

    • Enterprise operators should restructure permission policy: stop maintaining flat profile lists; build a base profile plus per-team derivations using inheritance.
    • Decide where `requirements.toml` lives (repo-rooted, org-rooted, signed) before depending on enforcement — the distribution and trust model are not yet documented.
    • Migrate off legacy profile configs; 0.134.0 rejects them with migration guidance.
    • Normalize permission selection on `--profile` as the canonical handle; flag-soup approaches are now legacy.
  3. 2026-05-12 · Codex

    PreToolUse hooks can now rewrite tool inputs before execution

    • Hook authors who returned updatedInput in PreToolUse hooks expecting rewrites to apply should re-test: prior to this fix, the original input was used; after this fix, the rewritten input is used. Verify existing hooks behave as intended after upgrade.
    • Operators can now build input-sanitizing PreToolUse hooks that modify tool arguments before dispatch -- path normalization, argument masking, destination redirection.
  4. 2026-05-11 · Codex

    Permissions glance surface and role-aware plugin sharing

    • Bitter receipts should record permission posture + approval mode as standard fields.
    • Plugin share role-awareness affects whether Bitter can share configs across roles.
    • Authority visibility in the TUI is a worked example of governance ergonomics worth borrowing.
  5. Persistent agent state is becoming a product surface

    • Developers need to know which goals, memory patches, recaps, sessions, and skill maintenance loops shaped a serious run.
  6. The agent interface is becoming a visible computer

    • A serious agent harness increasingly needs browser, desktop, file, runtime, sandbox, and artifact surfaces that can be inspected.
  7. Permissions, secrets, and sandboxes are moving into the foreground

    • The harness must make trust state visible: what can be read, what can be changed, which credentials are exposed, and where execution happens.
  8. Agent systems are growing control planes

    • Once agents coordinate across tasks, runtimes, gateways, and integrations, operators need liveness, cost, role, session, and recovery controls.
  9. Integrations are volatile; the operating loop has to be durable

    • Provider lists, plugin systems, transports, and model profiles will keep changing.
  10. 2026-05-06 · Codex

    Worker-native goals unlock longer horizons.

    • Operators now need to ask which durable objective the worker is pursuing, whether it is still aligned with the operator's charter, and how it maps to the current run mandate.
    • Treat worker goals as first-class receipt fields: goal id, goal text, creation source, last update, status, scope, originating run, mapped charter, mapped mandate, and settlement status.
  11. Authority semantics are explicit but fragmented.

    • Permission profiles, workspace trust, env loading, hooks, MCP behavior, extension schemas, and provider transports differ by worker and release.
    • Bitter capability profiles should record worker-native permission and trust semantics instead of assuming a uniform authorization model.
  12. Verification is becoming a worker capability.

    • Provider-native review, multi-agent execution, subagent evals, curator reports, and QA-like cloud fleets can catch useful issues, but their verdicts are not automatically the operator's truth.
    • Treat worker verification as evidence inputs. BitterQA or the run contract should still own the final evidence standard and settlement.
  13. Plugin, extension, and skill ecosystems are becoming the integration surface.

    • The practical power of worker CLIs increasingly depends on plugins, hooks, extensions, skills, and transport modules, not just the base model.
    • Adapter receipts should include enabled plugin/extension/skill surfaces and should distinguish worker-local skills from Bitter-owned memory.
  14. Worker integrations are not durable doctrine.

    • Pi removed built-in Gemini CLI and Antigravity support while adding many providers; Gemini preview/nightly channels differ materially; Codex alpha releases and app-server surfaces move quickly.
    • Keep worker adapters thin, versioned, source-contracted, and replaceable. The stable Bitter asset is the run contract and receipt chain.
  15. Provider-native long-horizon state is now table stakes.

← All signals