AF Arc Forge Docs
Overview

Arc Forge Console

Simple customer-facing documentation for how Console, managed OpenClaw agents, account connections, and support flows fit together.

Connect GoogleOAuth source, service grants, agent assignment, readiness checks, and reconnect behavior. Connect TelegramBot setup, delivery proof, listener checks, assignment, disable, and revoke behavior. Element 2 imagesScaffold for image-bearing Docs, Sheets, Drive files, screenshots, and edited artifacts. TroubleshootingKnown Console quirks and the safe evidence to include in a support ticket.

How it works

Arc Forge Console is the customer portal. It manages account access, billing state, device enrollment, integration setup, readiness checks, and support context.

OpenClaw is the agent runtime. These docs should explain the Arc Forge layer around OpenClaw rather than recreate the upstream OpenClaw manual.

Public-safe rule: browser pages and docs can show account labels, selected capabilities, readiness state, last probe status, and next actions. They must not show raw setup keys, OAuth refresh tokens, client secrets, keyring passwords, or private runtime paths.

Documentation map

The docs should stay small and task-first. Each article should start with the customer outcome, then list the expected Console flow, common failure states, and what support needs to know.

  • Overview: Console, OpenClaw runtime, status badges, support bridge, and secret boundaries.
  • Setup: account access, model provider sign-in, devices, and first agent readiness.
  • Integrations: Google, Telegram, iMessage, email, and future agent-scoped channels.
  • Troubleshooting: sign-in failures, OAuth warnings, stale permissions, missing images, and reconnect flows.

Account and access

Customers use Console to manage their account, plan, agent access, devices, and support tickets. Public docs should describe what each page is for without exposing deployment or tenant internals.

Codex sign-in

If ChatGPT or Codex sign-in says device code authorization is disabled, turn that setting on in the ChatGPT account that should own the OpenClaw model-provider session.

  1. Open ChatGPT in the browser account OpenClaw should use.
  2. Open Settings, then Security.
  3. Enable device code authorization for Codex.
  4. Return to Console and retry sign-in from the Model Provider card.

Devices

The device docs should explain secure desktop enrollment, platform-specific setup, and how Console reports device readiness. Keep raw one-time setup keys out of docs, screenshots, and support notes.

Google

Google is presented as one customer-facing integration even when the current runtime adapter uses gog internally. Normal Google accounts and Google Workspace accounts use the same customer flow; admin-only capabilities are separate gated paths.

1
Choose scopeSelect the agent and Google services, such as Gmail, Calendar, Tasks, Drive, Docs, Sheets, or Slides.
2
Confirm sourceUse Arc Forge-managed OAuth for the public lane. Runtime-configured and customer-owned clients are support or advanced lanes.
3
AuthorizeComplete Google consent in the browser, then return to Console.
4
Prove readinessConsole checks runtime prerequisites, selected services, account authorization, write checks, and revoke or disable controls.
Testing-mode note: while the Arc Forge Google app is in Testing mode, some accounts may need test-user admission and some refresh tokens can expire earlier than the approved public app. Reconnect Google if Console reports action needed.

Telegram

Telegram is an agent-scoped messaging integration. The customer-facing setup should prove the bot identity, message delivery, listener state, agent assignment, and disable or revoke behavior.

  1. Create or choose a Telegram bot and keep the bot token private.
  2. Enter the bot username, bot token, and target agent in Console when the Telegram setup form is available for the account.
  3. Run a delivery probe so Console can prove send and receive behavior.
  4. Disable in Console or rotate the bot token in Telegram when access should be revoked.

Element 2 images

Element 2 is the public-safe label for image-bearing document work where the agent can see document context but needs a separate artifact path for embedded images, screenshots, scans, or generated edits.

  • Keep Element 1 focused on structured text, tables, document metadata, and OpenDocs-style exports.
  • Track Element 2 images with source, MIME type, intended action, and write-back destination.
  • Use GIMP or other image tools only on authorized working copies.
  • If an image is missing, check Drive/file access, export support, MIME type, and external-link permissions.

Troubleshooting

Google reports action needed

Check whether the account is still authorized, the selected services match the job, the runtime prerequisites are ready, and the OAuth source is the one shown in Console.

Telegram does not receive messages

Confirm the bot token was not rotated, the bot username matches the token, the runtime listener is active, and the latest delivery probe passed.

Images are missing from a document workflow

Treat this as Element 2. Record where the image lives, what the agent should do with it, and whether the intended output is read-only analysis or an edited file.

Support tickets

Support tickets should include enough context to reproduce the issue without exposing credentials.

  • The Console page or integration involved.
  • The account or bot label, not raw secrets.
  • The status badge or action-needed message shown in Console.
  • For Google, the selected services and whether the issue is sign-in, readiness, write checks, or images.
  • For Telegram, the bot username and latest delivery-probe result.

Security boundaries

Docs, browser UI, support notes, and public examples should describe behavior and state, not secrets. Runtime-owned credentials stay on the owning runtime or approved secret path.