Connect your coding agent

​

Goal

Let your coding client request governed infrastructure work without requiring a native Stackie session.

​

Prerequisites

• Agent connections enabled for your account on the deployed backend.
• A supported client and access to the resources you intend to authorize.

​

Workflow

​

Start with an outcome (next release)

An empty agent conversation offers starting points for deployment, incident investigation, isolated previews, resource costs and restore verification. Selecting one fills an editable draft; it does not submit work, grant permission or create resources. Review the draft before sending. Use Manage → New objective to record success checks, a deadline and an AI budget. The objective panel puts outcome checks first. Verified means matching, current evidence for the recorded target and plan revision. Failed, unavailable, pending and stale checks remain distinct. A completed operation alone does not prove the intended outcome; expand Check details to inspect the recorded evidence and its validity period. Authority and budget shows native AI spending and authorized environments. Expand Permissions and spending details for the exact action scope and expiry. Infrastructure charges are separate from the AI limit; external clients bill their own reasoning, while separately authorized native tasks use StackShift AI funding. Native approval cards show the requested operation and risk explanation. Expand Inspect exact operation arguments before approving when you need the full payload. Approval allows execution; it does not verify success. Existing questions, retries, cancellation, operation activity and resource controls remain available for recovery.

​

One catalog, client-specific setup

The dashboard reads setup methods, commands, requirements and support information from the shared server catalog. Expand one client at a time to see its instructions. An install link starts client setup; it does not bypass browser authorization. Some clients use a local configuration or CLI command. Others require adding a hosted connector in the client account. Use the method actually displayed for your client, including its authentication step. Copy URL provides the MCP endpoint without a credential. A client logo or display name helps you recognize an entry; it does not verify the identity of software making an authorization request. Review the visible return destination and, when needed, expand Request details for the registered callback and request metadata. Agent workspace and resource actions open this same Settings destination. A resource hint is checked against your available resources and can place that resource first in the selection list. It remains unchecked: opening the link does not authorize access. Unavailable resource context is reported explicitly.

​

Your connections

You can have multiple connections for the same client. Manage opens the selected connection, including its owner, expiry, last observed use, authorized resources and permitted operations. Policy and client details contain supplementary authorization information. Authorized means access was granted. Last observed use records available authenticated-use evidence; None yet means no such use has been recorded. A CLI diagnostic probe does not prove that the selected client authenticated, and an idle connection is not automatically disconnected. The inspector separates current work from history. Expand operation details for available evidence. A failed operation remains failed even if a separate approval record is pending; approval does not restart or complete a terminal operation. For eligible pending work, open Review approval to inspect the proposed configuration, affected targets, expiry and available estimate before approving or declining. Technical details retain the action binding. After a lost decision response, retry the retained choice or refresh the recorded operation; an approved queued operation is still awaiting execution.

​

Credentials and recovery

A scoped credential is shown once. Store it using the supported client credential mechanism and keep it out of prompts, source control, screenshots and shared logs. If an issuance response is lost, retry the same request through the recovery control. A recorded issuance does not reveal the previous secret again. Use deliberate credential replacement when necessary; replacement invalidates the previous credential. Replacing a connection during browser consent revokes the old connection and preserves or reduces its access. It does not silently broaden the old grant. A lost authorization callback may require restarting client authentication rather than issuing another code from the same decision.

​

S2 bucket inspection and settings

Built-in and connected agents share the authorized storage_bucket inspection. It reports versioning, retention, tiering, quota, usage, encryption mode, website index and error pages, and the custom-domain attachment ID. Encryption keys and storage credentials are not returned. storage.settings.save changes versioning_enabled, default_retention_days and tier_after_days after the required approval. It preserves quota, website, encryption and domain configuration. Repeating the same approved operation does not apply the mutation twice; changed bucket revisions invalidate stale approval. The S2 multipart recovery, object-version, cold-restore and event-subscription APIs are separate interfaces, not additional permissions implied by bucket inspection or settings access. Discover available agent actions before proposing work; use the authorized S2 interface for operations absent from that catalog. Available actions are reported by the deployed capability catalog.

​

Reasoning and infrastructure charges

Your external client supplies the reasoning. Direct external work does not require Stackie, StackShift AI credits, an AI subscription or enabled native agent execution. Workloads on your server, including a VPS provisioned through StackShift, have no additional hosting charge and are bounded by server capacity. Server rental, shared hosting and separately purchased services retain their own charges. Connecting a client does not transfer its subscription allowance or API credits to Stackie. Stackie keeps its existing managed-credit and explicitly selected BYO API funding options. Choosing a separate native Stackie task retains those existing funding rules.

​

Typed discovery and environment support (next release)

MCP operation_propose advertises action-specific request variants from the canonical catalog for consented actions. Each variant includes its configuration schema, funding, approval and effects. Inspection actions remain available through their consented catalog entries. The existing proposal endpoint still owns validation, authorization, idempotency and independent approval. In the agent workspace, open Manage → Inspect capabilities. Choose a resource and configuration namespace, then use Capabilities for action availability or Context for full resource IDs, configuration, dependencies and operations. Supply resource_id from resource discovery and expected_resource_version from fresh context when acting on an existing resource. After an uncertain response, replay the identical idempotency key and body and inspect the retained operation. A target_changed response requires fresh context and review; invalid_request requires fixing the advertised payload. Native objective.resource_context and GET /api/v1/agents/resource-context accept environment=production, staging or preview and return environment.namespace, environment.isolation and the authorized application_id. The dashboard namespace selector uses this projection. Unsupported actions are unavailable for the selected namespace; dispatch still enforces the same restrictions. child_application identifies an actual isolated preview Application, while staging/preview are configuration namespaces. External connection context reports the same isolation identity with its fixed production namespace; it does not accept a namespace override or expose a hidden parent Application. Scheduled exact HTTP checks now honor the owner policy recovery window and observation count. Configure path, expected status, optional exact body and max_duration_ms in criteria. Failed, unavailable or changed-revision observations reset stability; rapid repeated reads do not add independent observations. This measures individual probes, not p95 or a traffic error budget. Existing schedule receipts, non-overlap, policy expiry, cooldowns and AI spending limits remain in force. Scale-to-zero remains unavailable. Current workload scaling requires at least one copy. Stopping workloads on your server does not reduce StackShift workload hosting charges because those workloads already have no incremental hosting charge. Request-triggered wake, cold-start guarantees and database sleep are not advertised.

​

Latency and error-rate policies (next release)

In Agent controls, create or edit a standing policy, select explicit public project targets and production configuration, and enable Monitor endpoint latency and error rate. Choose only the repair actions you intend to authorize, retain an expiry and AI spending limits, and confirm unattended authority. Child preview projects use their own production configuration namespace. External clients cannot create or expand these owner policies. The policy API accepts http_monitor with check: {path: “/health”, status_code: 200}, samples: 5, latency_ms: 1000, error_rate_percent: 40 and cooldown_seconds: 900. Include http.latency and/or http.error_rate in triggers for nonzero thresholds. Samples must be 3–10; cooldown is 300–86400 seconds. Status must be 200–299, latency 1–8000 ms and error rate 1–100 percent; zero disables that threshold. Monitor checks do not accept response bodies or their own max_duration_ms. Probes use the canonical active HTTPS deployment, without credentials or redirects, at least 60 seconds apart. A latency event requires every sample in the full window to exceed the threshold. Error rate is the fraction of probe responses that differ from the expected status. This is synthetic endpoint telemetry, not p95, a production-traffic error rate, or an SLO error budget. Failed connections, an eight-second timeout without a usable response, and missing targets are unavailable telemetry, not measured failures; these clear the sample window. Gaps over three minutes and deployment changes also reset the window. The worker persists the sample window and exact deployment identity. A qualifying window creates one policy-bound objective, retaining its source samples and correlation record. Existing active-incident suppression, approvals, AI budgets, deadline and intervention records apply. The recovery criterion requires the expected HTTP status and configured response-time limit throughout the owner policy stability window. Missing or failed verification cannot prove recovery. An incident remains open across unsuccessful repair deployments to prevent recursive repair. A complete healthy probe window closes it; cooldown is measured from the last dispatch. Exhausted authority cannot create a new objective. The owner can inspect the objective, revoke the policy, or explicitly revise it. Policy revisions begin a new monitor configuration. Memory remains owner-reviewed; probe outcomes do not silently become standing instructions. Application graph nodes expose source_type and, when an active deployment exists, active_runtime with deployment_id, workload_id, runtime_kind, source_revision and the public hostname. HTTP events identify the same project and deployment so evidence can be traced to that graph node. Undeclared external dependencies are not inferred.

​

StackShift-owned operational events (next release)

In Manage → Agent controls, edit or create an owner policy and enable the desired StackShift-owned events. Queue, cost and drift monitors require one owned project in its production configuration. Restore-test monitoring requires a separate policy with one owned database in production configuration. Select only intended actions, an expiry and existing AI spending limits, then confirm unattended authority. These changes are implemented for the next release, not a claim about the deployed server. The policy API accepts signal_monitors, with one entry per enabled kind and matching triggers. Examples: {kind: “queue.depth”, queue_name: “orders”, depth: 100, age_seconds: 300, cooldown_seconds: 900}; {kind: “cost.anomaly”, increase_percent: 100, min_increase_kobo: 100000, cooldown_seconds: 900}; {kind: “runtime.drift”, cooldown_seconds: 900}; {kind: “restore.test”, age_seconds: 604800, cooldown_seconds: 900}. Cooldowns range from 300 to 86400 seconds. These example thresholds are configurable, not enabled by default. queue.depth counts due, claimable customer HTTP jobs in the explicitly selected account-owned durable queue that have waited at least age_seconds. It includes paused-queue backlog, excludes future jobs, active leases, exhausted attempts unless resumable, and internal platform execution. Queue ownership is account-level; selecting a project policy explicitly associates that queue with the intended remediation target, not an inferred callback-URL relationship. Depth is 1–1000000 and age is 60–604800 seconds. External Redis and RabbitMQ queues are not observed. cost.anomaly compares signed usage_records costs for the last complete UTC day with the daily average of the preceding seven complete days. All eight days need records and the rounded baseline must be positive; missing data is unknown. Both the configured percentage and minimum increase must be met. The settlement unit is NGN/kobo; the UI accepts NGN and the API min_increase_kobo accepts its minor unit. The increase range is 1–10000 percent and the minimum is 1–100000000000 kobo. This measures posted StackShift usage, not exact consumption time, an all-in bill or external provider costs. Existing free deployment rules, billing and limits are unchanged. A late posting can affect the comparison, and the next complete-day window may be needed to demonstrate recovery. runtime.drift uses reports no older than three minutes that match the current node generation, manifest hash and control-plane timestamp. Only observations matching this project’s resource IDs, types and keys count. Other tenants on the same server, missing reports and in-progress deployment observations cannot imply an incident or recovery. It does not monitor arbitrary file changes inside a server. restore.test checks validations attached to artifacts from the selected source database. The latest terminal failed, incompatible or corrupt result triggers an event; a queued validation cannot hide it. A missing or overdue successful test is reported as unverified recoverability, not proven corruption. Successful-test age is 3600–7776000 seconds (one hour to 90 days); the UI uses hours. Platform engine-family sample tests do not substitute for this database’s evidence. Monitoring does not run an overwrite restore; any validation or repair still requires its existing action authority. The worker samples these sources at least one minute apart, persists incident state, and creates at most one active event objective per resource. Events retain the source observation and cannot be supplied through the external event-dispatch endpoint. Each generated objective includes a server-bound operational-signal verifier: health of an unrelated controller cannot prove recovery. Fresh healthy observations must satisfy the policy stability window, and a changed source revision resets recovery. Incident rearming requires five minutes of fresh healthy samples plus the configured cooldown. Unknown telemetry resets recovery, not the open incident. A two-hour objective deadline, policy expiry, budgets and approvals still bound the work; unresolved events require owner intervention. Editing a policy begins a new monitor version.

​

Available capabilities and observed results

Agent connections are deployed. Use the current capability catalog for supported actions and the operation record for actual execution results. New features explicitly marked for the next release are not part of that deployed baseline. Owner-tested production MCP integrations are the existing baseline. Typed objective checks, repository smoke actions, revised recipe quotes and preview outbound restrictions in this implementation are next-release changes. Do not infer deployment from a passing local test or an installed client. If connection or operation sources cannot be read, the interface reports that limitation. Retained data may be stale; an unavailable source does not mean there are no connections or that work succeeded.

​

Expected result

​

Common failures

​

Related guides