.env.e2e.example

# E2E Test Environment Variables
#
# Copy this file to .env.e2e and fill in your values before running:
#   npm run test:e2e
#
# Tests targeting a node are automatically skipped if the corresponding URL
# env var is not set. If both node URLs are unset the entire suite is skipped.
#
# Dual-node tests (concurrency, cross-node isolation) only run when both
# E2E_NODE_OPT186_URL and E2E_NODE_WINDOWS_URL are set.

# URL of the opt186 Ubuntu slave node
# E2E_NODE_OPT186_URL=http://192.168.88.186:4096

# URL of the Windows slave node (replace <windows-ip> with the actual IP)
# E2E_NODE_WINDOWS_URL=http://<windows-ip>:4096

# Shared credentials for all nodes
# E2E_NODE_USERNAME=opencode
# E2E_NODE_PASSWORD=your-password

# ── Permission-aware tests (fleet_reply_permission) ───────────────────────────
#
# The permission E2E tests in tools.e2e.ts work in two modes:
#
#  1. Injected state (always runs when a node is configured):
#     Uses injectPermissionForTesting + injectStatusForTesting to simulate a
#     pending permission request. Verifies fleet_get_session_status output
#     includes the permission paragraph. No live pending permission needed.
#
#  2. Live HTTP (always runs, but expects 404/error since no real permission):
#     Calls fleet_reply_permission against a non-existent permission ID and
#     asserts that the handler returns isError=true. Verifies the error path
#     when the slave has no matching pending permission request.
#
# To test with a real live pending permission (slave is blocked at ask prompt),
# start the slave WITHOUT --auto, trigger a permission-requiring tool call, then
# run the E2E suite. No extra env var is needed — the handler test will succeed
# (HTTP 204) instead of returning an error. This scenario is not automated
# because it requires manual slave setup and is not repeatable in CI.