@ory/opencode 0.6.2 → 0.7.1

package/README.md

@@ -63,13 +63,13 @@ From any project where you'd like Ory authentication, inside OpenCode:
 
 3. **Sign in.** Start your app, visit the login page OpenCode added, and sign in with the seeded credentials. You now have a real Ory session backed by a real Ory stack — locally, offline, with zero configuration.
 
-4. **Turn on Ory login for the OpenCode session itself.** *(Optional but recommended.)* Out of the box the plugin only governs your *app*. To also attach an Ory identity to *OpenCode's* session — so every tool call is attributed to you, not a fallback `session:<id>` subject — set:
+4. **Turn on Ory login for the OpenCode session itself.** *(Optional but recommended.)* Out of the box the plugin only governs your *app*. To also attach an Ory identity to *OpenCode's* session — so every tool call is attributed to you, not a fallback `session:<id>` subject — opt in to the user-login flow:
 
    ```bash
-   export ORY_AUTH_GATE=1
+   export ORY_USER_LOGIN=1
    ```
 
-   Then restart OpenCode. On next session start, OpenCode opens an Ory login in your browser; sign in with the same seeded credentials from step 1. This is what makes `permissions enforce` (see [Agent security](#agent-security)) deny on the right identity later. (Note: OpenCode's session-start primitive can't hard-block, so the gate runs in advisory mode — auth still happens and the audit trail is correct, but the session always proceeds.)
+   User login is off by default. With it on, the next OpenCode session opens an Ory login in your browser; sign in with the same seeded credentials from step 1, and the token is reused on subsequent sessions until it expires. This is what makes `permissions enforce` (see [Agent security](#agent-security)) deny on the right identity later. (Note: OpenCode's session-start primitive can't hard-block, so the flow runs in advisory mode at session start — auth still happens and the audit trail is correct, but the session always proceeds. Per-tool enforcement at `permission.ask` is unaffected.)
 
 That's the full Ory DX path. Stop here if you're just evaluating the plugin. Continue to [Agent security](#agent-security) when you're ready to enforce.
 
@@ -124,7 +124,7 @@ Without configuration the plugin still loads cleanly and runs in **pass-through
 
 Once the plugin is pointed at an Ory project (local or hosted), OpenCode's session and every tool call can be governed by Ory.
 
-- **Authentication.** Two identities. The human at the keyboard (the **user**) authenticates interactively via Ory Identities when `ORY_AUTH_GATE=1` is set. The OpenCode process (the **agent**) gets its own OAuth2 identity, self-registered via [Dynamic Client Registration (RFC 7591)](https://datatracker.ietf.org/doc/html/rfc7591) on first run.
+- **Authentication.** Two identities. The human at the keyboard (the **user**) authenticates interactively via Ory Identities when user login is enabled (`ORY_USER_LOGIN=1`, off by default — browser PKCE flow on first session, persisted token thereafter). The OpenCode process (the **agent**) gets its own OAuth2 identity, self-registered via [Dynamic Client Registration (RFC 7591)](https://datatracker.ietf.org/doc/html/rfc7591) on first run.
 - **Authorization.** When OpenCode prompts for permission to use a tool, the plugin checks [Ory Permissions](https://www.ory.com/docs/keto) (Zanzibar-style relation tuples) against the user's subject and returns `allow` / `deny`. A parallel pre-tool check is recorded as part of the audit trail. MCP tool calls additionally get a server-level check.
 - **Audit.** Every decision (allow, deny, fallback) is recorded as a structured trace span: NDJSON file output and/or OTLP/HTTP export to Jaeger, Honeycomb, Grafana, and similar collectors. The user → agent delegation is written to Ory as a relation tuple so *"agent X acting on behalf of user Y"* stays queryable after tokens expire.
 
@@ -134,10 +134,10 @@ The plugin is **fail-open** on its own infrastructure failures (network errors,
 
 After install the plugin runs in **observe mode**: every tool call is checked against Ory Permissions, but a deny is recorded as a `permission.observe_deny` audit span and the tool runs anyway. This lets you see what *would* be blocked before turning on hard blocking.
 
-1. **Turn on the user gate.** In your shell:
+1. **Turn on user login.** It's off by default. In your shell:
 
    ```bash
-   export ORY_AUTH_GATE=1
+   export ORY_USER_LOGIN=1
    ```
 
    The next OpenCode session refreshes or prompts for PKCE login. Subsequent sessions reuse the persisted token until it expires.

package/dist/plugin.d.ts

@@ -1,8 +1,8 @@
 import { OryAgentClient, ensureUserAuthenticated, ensureAgentIdentity } from "@ory/argus";
 import type { PluginModule } from "./types.js";
 export interface CreateOryPluginDeps {
-    /** Test injection point for the user auth gate. */
-    authGate?: typeof ensureUserAuthenticated;
+    /** Test injection point for the user login flow. */
+    userLogin?: typeof ensureUserAuthenticated;
     /** Test injection point for the agent identity gate. */
     agentGate?: typeof ensureAgentIdentity;
 }
@@ -14,7 +14,7 @@ export interface CreateOryPluginDeps {
  * (input, output) => Promise<void> pattern.
  *
  * The `server` factory has no return-value channel for blocking, so the
- * auth gate runs in advisory mode at startup — it emits the audit span,
+ * user login runs in advisory mode at startup — it emits the audit span,
  * refreshes tokens, and may launch a browser flow when interactive, but
  * cannot prevent the session from starting.
  */

package/dist/plugin.js

@@ -10,7 +10,7 @@ const argus_1 = require("@ory/argus");
  * (input, output) => Promise<void> pattern.
  *
  * The `server` factory has no return-value channel for blocking, so the
- * auth gate runs in advisory mode at startup — it emits the audit span,
+ * user login runs in advisory mode at startup — it emits the audit span,
  * refreshes tokens, and may launch a browser flow when interactive, but
  * cannot prevent the session from starting.
  */
@@ -79,13 +79,13 @@ function createChatMessageHandler(client) {
 }
 // ─── Session verification on startup ────────────────────────────────
 async function verifyOnStartup(client, deps) {
-    // Run the user auth gate. The OpenCode `server` factory has no block
-    // primitive, so allowBlock is false — the gate emits the user.auth
+    // Run the user login. The OpenCode `server` factory has no block
+    // primitive, so allowBlock is false — the flow emits the user.auth
     // audit span, refreshes tokens, and may prompt the user, but never
-    // prevents the session from starting. When ORY_AUTH_GATE is unset the
-    // gate is a no-op (mode === "disabled") and we fall through to legacy
+    // prevents the session from starting. When ORY_USER_LOGIN is unset
+    // it's a no-op (mode === "disabled") and we fall through to legacy
     // logging.
-    const userGate = deps.authGate ?? argus_1.ensureUserAuthenticated;
+    const userGate = deps.userLogin ?? argus_1.ensureUserAuthenticated;
     const decision = await userGate(client, {
         binName: "ory-opencode",
         harness: "opencode",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ory/opencode",
-  "version": "0.6.2",
+  "version": "0.7.1",
   "description": "Ory plugin for OpenCode: scaffolding skills, a local Ory instance, and authentication, authorization, and audit for every tool call",
   "license": "Apache-2.0",
   "homepage": "https://ory.com",
@@ -63,7 +63,7 @@
     "!dist/**/*.tsbuildinfo"
   ],
   "dependencies": {
-    "@ory/argus": "0.6.2"
+    "@ory/argus": "0.7.1"
   },
   "engines": {
     "node": ">=22"