Using the WebUI — authentication settings (「認証」)
Any screen not listed here does not exist. Headings quote the screen's own wording.
Part of the settings guide. Other topics:
conversations, the input box, and sign-in: references/webui.md;
documents, files, tables, memory, channels, and apps: references/webui-workspace.md;
editing a file in place (「編集」): references/webui-file-edit.md;
SIROE pages, blocks, and boards: references/webui-siroe.md;
settings, administration, models, and triggers: references/webui-settings.md;
external service connections: references/webui-connections.md;
/office: references/webui-office.md;
/meetings: references/webui-meetings.md;
/calendar: references/webui-calendar.md.
「認証」
| Where | What it configures |
|---|---|
/settings/connections |
「コネクタ」. External service connections (connectors, API connections, use from external AI). Details are in references/webui-connections.md — how to connect, company-wide shared accounts, and what each SaaS can do from chat are there. 「SmartDB」 on the same tab is connected by admins and managers with a binder token; there is no per-user identity check — it acts as the token's robot user (only the registered binders are reachable) |
/settings/secrets |
Keys for external services. There is no way to read them back (only to enter and pass them). Scope has 3 levels — 自分のみ / グループ / テナント全体 — and for the same name, 自分のみ > グループ > テナント全体 wins in that order |
/settings/browser-logins |
Login state used by browser operation. After finishing a login in Live View, the domains passed through along the way are offered as 「共通ログイン」 candidates — none are selected by default, and only non-blocked domains can be chosen. Once selected and saved, that domain's cookies are injected into the browser first whenever any site is opened. The scope is the same as that site's registration, and the candidate section shows something like 「公開範囲はテナント全体(このサイトと同じ)」 — selecting on a tenant-wide registration injects into everyone's browser. The 「サイトを追加」 form first asks 「保存するもの」 as two cards — 「ID とパスワード」 (selected by default; needs 「ログイン画面の URL」 — there is no 「ドメイン」 field: the registration's domain is the login URL's domain, so a site whose login page is on another domain, such as auth.example.com, is registered with that login page's URL) and 「ログイン済みの cookie」 (enter the 「ドメイン」; log in afterwards with 「ログインして保存」, or paste cookies). The cookie-login registration form has a 「共通で使う」 checkbox, and shared-login rows in the list carry a 「共通」 badge. Multiple accounts can be registered for the same site — the list is grouped by host, and any number of registrations with different names can sit under the same host and scope (the name is 「ログインの名前」 in the registration form; duplicates are not allowed within the same host and scope; 「編集」 can rename it, with a warning that chats, skills, scripts, and workflows naming the old name stop working until fixed, and a cookie row and ID/password row sharing the name are renamed together). A host with 6 or more rows starts folded; press the domain line to open it. 「一括登録」 registers ID/password rows in bulk from a pasted spreadsheet range or a CSV file, up to 200 per run: columns are login URL, ID, password, name (optional), logout URL (optional), in any order when a header row is present; an empty name becomes the ID, and an existing name is skipped, never overwritten. The row's radio button is 「既定」, used when a conversation or script does not specify a name — for a host with several rows and no default, operations that do not specify a name are refused. To choose from a conversation, pass the name to browse's navigate (passing a different name logs out of the previous login before opening). Each row shows one next-step button — 「ログインして保存」 (cookie) or 「入力」 (ID and password), outlined while the row is 「未設定」 — and folds the rest (「貼り付け」 for cookie rows, 「編集」, 「複製」, 「失効」) into its 「…」 menu. Registering an ID-and-password login opens the ID/password input right away. A row's 「編集」 fixes the login URL (within the same domain — a login URL on another domain is refused with 「ログイン URL には samuraiapp tunnel browser). It lists here as a private login, never overwriting company-wide or group-shared accounts. Once saved, the card says 「次からは、このサイトを開くよう頼むだけで、ログイン済みで開きます」 — from then on, just ask the AI in any chat to open the site; there is no need to log in again. Its optional 「ログインの名前(任意)」 defaults to the domain; a name already used replaces that login. Its 「ID とパスワードで保存」 saves the ID and password instead (one or the other) — for sites whose cookies expire quickly. Its 「ログイン画面の URL」 is pre-filled with the page where the password was typed, and the row is registered under that login page's domain (shown as 「auth.example.com to log in, that is auth.example.com, not the site you opened. For an SSO login where the password is typed on one domain and the browser lands on another (Google's accounts.google.com → myaccount.google.com, Microsoft's login.microsoftonline.com → Microsoft 365), the card appears for the domain landed on, and the domain where the password was typed is pre-selected as a 「共通ログイン」 candidate so other services of the same IdP open signed in too — unchecking it saves only the landed domain. When saving, renaming, moving, or revoking a login is refused (or the Live View login cannot be saved), the screen shows the reason and what to do next, with a small line beneath it: 「エラーコード: BC-40007 ・ 問い合わせ番号: 7f3a9c21」 — pass both when asking support. For example: the same scope already has a login with that name (BC-40007: pick another name), pasted cookies could not be read (BC-40002: paste them as SESS=…; CSRF=… or a cookie JSON array), the login was not finished or someone else manages the same login (BC-40003: finish logging in and try again), or an admin blocked the domain (BC-40008) |
/settings/cli |
「PC と繋ぐ」. The 「インストール」 tab opens with a 5-step guide — open the terminal (Terminal / PowerShell, with the keys) → install → sign in → register this machine (the standard-settings tunnel register line) → connect (tunnel serve / tunnel install). Only the current step is open; 「できた」 moves on, and register and connect also advance by themselves once the device appears in the list (「最初から」 resets). Composing the connect command in detail (tunnel register with the standard settings is on the 「使う」 tab — a single line allowing read/write of ~/Downloads, script execution, and browser operation (including typing and clicking); changing the allowed folders and capabilities rewrites it on the spot. The settings are split by permission into 5 steps — 「どのフォルダを許すか」 (presets, a typed path, and 「端末でフォルダを選ぶ」: turning it on adds --pick-folder, so running the command opens the OS folder dialog on that machine and adds the chosen paths), 「フォルダの中でさせること」 (「読むだけ」「読み書き」「スクリプトも実行」, plus 「フォルダの中のファイルの削除も許す」), 「ブラウザ」 (a switch, on by default; 「見るだけ」 or 「入力や押下も」; which browser — 「専用の Chrome」「専用の Edge」「普段使いの Chrome」 — with the profile name or the CDP address for the chosen one; for a dedicated browser, 「ウィンドウを出さずに動かす」 adds --headless, and recording still opens a window), 「PC のアプリ」 (a switch, off by default, macOS / Windows only — adds --desktop write (「見るだけ」: read) and shows the cua-driver setup for the OS), and 「手元の Claude Code」 (a switch, off by default — adds --agent claude-code and shows how to install and sign in to Claude Code; see the CLI reference for its limits). Only 「そのほかの設定」 (device name, per-file limit, expiry) is folded. Removing all folders (with 「端末でフォルダを選ぶ」 off) hides it. The 2 commands to run next — 「いま 1 度だけ繋ぐ」 (tunnel serve; connected only while that window stays open, Ctrl-C stops it) and 「ログインしたら自動で繋ぐ」 (tunnel install; connects at every login, stopped with tunnel uninstall) — are shown regardless of input. Registering alone does not connect; recording does not need it). 「自分の作業を録って手順にする」 opens with what each stage needs — 録る: the browser grant, 会話にする: sign-in, neither needs the device connected; only 「できた手順を動かす」 needs serve / install, plus the list of registered devices and revocation (each row names what it allows in the builder's words — folder 読むだけ / 読み書き・削除, scripts, browser, app control, and 手元の Claude Code). Expiry defaults to 30 days, maximum 365 days, and is extended each time it connects. Registration itself happens only on the device — the screen only makes a string to paste. The surface is split into 3 tabs — 「インストール」「使う」「登録した端末」 (?tab=install / use / devices), and the OS (macOS / Linux / Windows) is chosen at the very top of the surface — it can be changed from any tab, and the install steps, the quoted connect command, and the removal steps all change together. How to stop using it is on the 「登録した端末」 tab — opening 「使うのをやめる」 lists 4 steps with commands: stop auto-start → revoke → sign out → delete the binary and settings (the order matters; logout does not stop the resident process). 「フラグを覚えずに画面で操作する」 shows samuraiapp with no arguments — running it opens an interactive screen in the terminal for sign-in, registering and connecting this machine, and recording work (no flags needed: arrow keys and Enter, typing only the MCP URL, folder paths, and machine name; close with 「終了」 in the menu. From a script or CI it shows the command list instead). 「手元のエージェントへ使い方を渡す」 downloads the usage of samuraiapp as a skill — extract samuraiapp-cli.zip and place it under ~/.claude/skills/, and a local Claude Code or similar knows how to call it (the host and tenant ID at download time are embedded) |
/settings/chat-surfaces |
「外部チャット」. Registering a Slack workspace, or a Microsoft Teams / LINE / Chatwork bot, or a Facebook page (Messenger), lets people call the agent from any channel, group, or room the app or bot has been added to — no channel or room ID is entered; the form asks only for the platform, the two secrets, and an optional display name; the workspace or bot comes from the token. One Slack workspace can be registered by only one tenant. For Chatwork, the webhook must be the account event for mentions to the bot. The add form's 「つなぐ手順」 lists, for the chosen platform, a link to that service's console, what to do before and after adding, and the settings that break silently. For Slack, 「Slack でアプリを作る」 opens Slack's create-app page prefilled with a manifest for this tenant; 「マニフェストをコピー」 copies it for an existing app's App Manifest page. For Microsoft Teams, entering the Azure Bot's Microsoft App ID there enables 「Teams アプリをダウンロード」, which saves the zip to upload to Teams; with 「チャンネルに入れる」 on, the zip also carries the permission to read channel messages. An app made earlier in the Developer Portal keeps working; uploading this zip adds a separate app. Only admins and managers can create, delete, or change them — pausing and resuming, switching the calling mode, and renaming a channel with 「編集」 in the row's 「その他の操作」 menu (on a LINE channel the same dialog changes the text people use to call the agent); for everyone else these are greyed out. The platform, the workspace or bot, and the secrets cannot be changed; to change them, add the channel again. The default is 「呼ばれたときだけ返答する」; a DM to the Slack app counts as a call. Nothing runs until the caller has completed linking — the first time, a linking notice visible only to them is returned (in Slack it carries a 「Samurai App と紐付ける」 button; elsewhere a link to /chat-link, valid for 1 hour); open it while signed in to Samurai App and press 「紐付けを確定する」. The triggering request then continues; the reply arrives in the original thread. In Slack, with 「Agents」 enabled in the Slack app (set by the manifest), the thread shows a working status and the reply is written out as it goes, with each step (search, reading files, etc.) shown as a task in it; without it, the reply arrives as one message after it finishes. Replies grounded in personal-permission files still go only to the requester and are never streamed. Teams, LINE, and Chatwork always reply in one message. Both tokens are tenant-shared secrets, picked or added right in the form. Each row shows its two secret names; Slack apps in one workspace cannot share a Signing Secret (CS-40013). Each call starts a conversation per thread, and answers are posted back there (no narrowing; replies grounded in personal-permission files can also appear). They appear neither in the history nor in 「すべての会話」 — read them at /settings/chat-surfaces/<連携先>. 「チャンネルに入れる」 (row 「⋯」) and choosing which channels and rooms appear there: references/webui-workspace-channels.md. When a Samurai App URL (a siroe page, or a file's public URL) is pasted in Slack, a card with its title and opening lines appears only if the person who pasted it has completed linking and can read it — the card is visible to everyone in the channel. This needs link_shared and 「App unfurl domains」 in the Slack app (set by the manifest). Elsewhere (Notion, X, etc.) only public URLs of files and conversations (「外部公開」) (the file name, or the conversation's title — never its messages) and public apps (their title and description) show a title; every other URL shows a card with just 「Samurai App」. Several bots in one place: one Slack workspace can hold several apps as separate connections (Teams / LINE / Chatwork already take one connection per bot), and each connection picks its 「応答するボット」 from bots shared with the tenant (personal bots cannot be picked; a deleted or unshared bot falls back to the default AI). When a registered bot mentions another registered bot, the called bot runs with the permissions of the person who first called a bot, stops after 3 calls with a private notice to that person, and a person mentioning a bot again resets the count. Calls from bots that are not registered here never run. Where another bot is present, the reply arrives as one message instead of streaming. Delivery between bots has not been confirmed on real workspaces yet. When adding, changing, or deleting a channel, unlinking, or confirming a link at /chat-link is refused, the screen shows the reason and what to do next, with a small line beneath it: 「エラーコード: CS-40003 ・ 問い合わせ番号: 7f3a9c21」 — pass both when asking support. For example: the bot is already registered in this workspace (CS-40003: use the existing channel) or in another workspace (CS-40901: ask support with the code); the service rejected the token (CS-40007: check the saved token); the service could not be reached (CS-40009: wait and try again); the link expired or was already used (CS-40006: call the bot again for a new link) |
/settings/approvals |
Two tabs: 「承認者」 (the approver roster, the default) and 「依頼」 (approval requests and each approver's answer). External people can be registered too (members: 「メンバーから選ぶ」). The deadline defaults to 72 hours, maximum 30 days; up to 5 approvers per request, and anyone, members included, can register approvers — a member sees and edits only the approvers they registered, while admins and managers see and edit everyone's; if not everyone answers by the deadline, it is not approved and the conversation continues with that result. Approvers receive an email titled 「【承認のお願い】」 and open its link (/r/) without signing in — pressing 「承認する」 or 「却下する」 sends a 6-digit confirmation code to the same address (valid 10 minutes), which they enter to confirm. An approver whose email matches a member's verified account email shows a 「メンバー」 badge; that member also gets a browser notification and an entry in 「受信トレイ」, and can approve or reject inside the app at /approvals/ without a confirmation code (the email link still works too). It passes when everyone approves; a single rejection makes it not approved |