System and sign-in configuration

Review system and authentication configuration together. Each section explains the change scope, secret handling, and failure behavior.

System and product settings

Product settings

The current page may expose non-sensitive settings such as product display name and default language. Saved updates use a shared revision and take effect without service restart.

Permanent audit records the actor, setting key, before and after values, and request metadata.

Read-only deployment configuration

Database, Redis, MinIO, document processing, other runner runtime parameters, file limits, JWT/HMAC/encryption keys, token periods, and retention remain in controlled .env or deployment configuration.

The page may show a redacted configured state but never connection strings, complete internal endpoints, passwords, keys, tokens, or encryption material. Model channels are an explicit exception managed on the Model Settings page.

Task concurrency

The Task concurrency tab lets administrators override two deployment defaults:

• The system-wide running task limit caps running tasks across all users.
• The per-user task process limit caps Codex app-server processes loaded by each user worker.

Leaving either field blank keeps the corresponding deployment default. New task starts read the latest saved settings without a service restart. Lowering a limit does not interrupt running tasks; new task or process admission pauses until current usage falls below the new limit.

System update

System update is a separate administrator page that checks official GitHub releases and shows the safe upgrade workflow. The web page never upgrades the deployment silently. See Check for and install LinkSense updates for preparation, host commands, and post-upgrade verification.

Scheduled maintenance

Open the System maintenance tab, enter a reason and the start and end times, then enable scheduled maintenance. Maintenance becomes active only when the current time enters the configured window and ends automatically at the specified end time.

When maintenance ends, the system automatically turns off scheduled maintenance and clears the reason, start time, end time, and duration. No additional save is required, and cleanup runs even when no administrator has the settings page open. An open settings page updates within a few seconds. Maintenance that ended while the service was stopped is cleared when the service starts again.

During active maintenance, signed-in administrators see a System maintenance enabled dialog on pages other than sign-in and maintenance settings. Select Don’t show again to hide it for the current maintenance period, for your account in this browser. The choice survives navigation, refreshes, and reopening the browser, and synchronizes across tabs. Editing the maintenance details or extending the current period does not show it again; starting a new period does. Other accounts and devices are unaffected. Select Maintenance settings to open the configuration page directly. The reminder stays hidden on that page, including after a refresh or repeated navigation. The close button and Esc dismiss only the current page’s reminder; navigating to another page shows it again. The dialog disappears when maintenance ends or is disabled and never appears on the sign-in or maintenance settings page. A System maintenance enabled link also remains in the bottom-right corner of signed-in administrator pages and opens maintenance settings. Closing or suppressing the dialog does not hide this indicator; it disappears when maintenance ends.

During maintenance:

• Regular users see the reason and expected maintenance window on a dedicated page and cannot call business APIs.
• Administrators can still sign in and use the system to inspect status, adjust the schedule, or end maintenance early.
• Sign-in, initialization, health, and current-user identification remain available so administrators cannot be locked out.

Confirm the device time zone before saving and provide a realistic end time.

Conflict and failure

Revision checks prevent one administrator from silently overwriting another. On conflict, refresh, inspect the latest state, and confirm the change again.

The server rejects attempts to alter a deployment-only setting even when a custom request bypasses the UI.

Recommendations

• Change organization-wide display settings during a low-risk period.
• Validate results with a regular user account.
• Use the separate authentication sections for login capability changes.

Authentication email and sign-in methods

Configuration modes

Authentication email, enterprise SSO (OIDC), and sign-in within Teams support:

• Inherit deployment environment;
• Managed in system settings with encrypted storage;
• Disabled, with no environment fallback.

Changing away from managed mode or disabling configured authentication requires confirmation.

Authentication email

Configure SMTP host, port, STARTTLS or direct TLS, sender, optional username, and password. An empty username means no SMTP password authentication. This service sends first-password and reset email; verify its connection in System Health.

Open registration

Enable open registration under Sign-in methods → Third-party accounts. Self-registered users share the member weekly quota standard in Quota management with users created or imported by administrators.

Disabling open registration blocks new requests and invalidates activation links that were issued but not yet used. It does not delete accounts created directly by administrators, existing activated accounts, or other configured sign-in methods.

Enterprise accounts

Use organization-managed accounts. New accounts require administrator activation regardless of the open registration setting.

Enterprise SSO (OIDC)

Enter an HTTPS issuer URL, client ID, and client secret. LinkSense derives and displays a read-only callback URL that must also be registered with the provider.

A new revision invalidates an unfinished callback started under an old revision. The user must restart sign-in. A first-time SSO identity creates a pending account by email; an administrator must enable it before the user signs in again.

Enterprise SSO (SAML 2.0)

Configure HTTPS for the site, then enter the identity provider's entity ID, sign-in URL, and PEM signing certificate. Register the displayed service provider entity ID and ACS callback URL with your provider, or save and enable SAML to download and import the XML metadata.

The provider must sign assertions and supply accurate, organization-managed email addresses. Match the email attribute name exactly; enter NameID to use that identifier as the email address. The name attribute is optional. Existing accounts are matched by email and retain their roles. New accounts need administrator activation; disabled accounts cannot sign in.

If your provider requires signed authentication requests, enable request signing and enter the service provider RSA certificate and matching private key. Saved keys are never returned; leave the private key blank when changing other fields. Saving with request signing disabled removes that certificate and key. Replace expired identity provider certificates to restore sign-in.

Members start from Sign in with a SAML enterprise account on the LinkSense sign-in page. Complete each flow within five minutes; restart after a configuration change. This version supports SP-initiated sign-in only, without IdP-initiated sign-in, encrypted assertions, or single logout. Signing out of LinkSense does not sign out of the identity provider.

Sign in within Teams

Enter Microsoft Entra tenant and client IDs. LinkSense settings do not replace Entra registration, Application ID URI, Teams manifest, or administrator consent.

Third-party accounts

Configure Google, Apple, Microsoft personal accounts, Facebook, and GitHub. For Microsoft work or school accounts, configure Microsoft Entra ID under Enterprise accounts.

For GitHub, create an OAuth App in developer settings and copy the callback address from the configuration dialog into Authorization callback URL. Enter its Client ID and Client Secret in LinkSense and enable it. Create separate apps for test and production environments with different callback URLs. Sign-in only requests email access, not repository access. If GitHub cannot provide a verified email, new users must verify their email through LinkSense.

When registration is open, new users can start after email verification without administrator activation. Existing users must sign in first and link their account under Settings → Security → Linked third-party accounts; matching emails are not merged automatically. Closing registration does not block sign-in for linked accounts.

Secret handling

The API returns only configured flags, never SMTP passwords or OIDC secrets. In managed mode, leave an unchanged secret blank; switching from another mode requires entering it again.

Corrupt or undecryptable configuration fails closed and never falls back to an unconfirmed old value.