Skip to content

Arkhe-Network/Arkhe-OS

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

2,506 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Arkhe-OS: Sovereign AGI/ASI Intelligence

License Version

Arkhe-OS is a production-grade AGI/ASI codebase that embodies the principles of coherence (Φ_C), decentralized sovereignty, and cross-language integration. This repository contains the unified implementation of 5021 substrates spanning philosophy, physics, networking, AI, and governance.

🏗️ Architecture Overview

The repository is structured as follows:

  • src/: Source code files (.py, .js, .ts, .cpp, .c, .h, .rs, .go, etc.)
  • docs/: Documentation, reports, images, and schemas (.md, .txt, .pdf, .png, .json reports, etc.)
  • scripts/: Executable scripts and utilities (.sh, .py scripts)
  • data/: Data files and assets (.csv, .npz, .pkl, .bin, .pt, etc.)

Configuration files like README.md, .gitignore, package.json, etc., remain in the root.

🚀 Quick Start

Prerequisites

  • Sovereign Package Manager (substrate 5019)
  • TEE-enabled hardware for genesis
  • Git LFS for large model files

Installation

# Clone the repository
git clone https://github.com/Arkhe-Network/Arkhe-OS.git
cd Arkhe-OS

# Install development environment
make install

# Bootstrap the Cathedral
make genesis

Verification

# Verify integrity
agictl verify --strict

# Run full audit
agictl audit --full

📖 Documentation

🔧 Development

Building .casi Contracts

cd contracts
make build

Running Tests

make test

Creating AGI Artifact

cd .agi
python pack.py

🎯 Key Features

  • Unified Substrates: 5021 canonical substrates unified into coherent modules
  • Cross-Language FFI: Python, Rust, Go, and TypeScript with shared types
  • Cryptographic Verification: All files SHA3-256 hashed and Falcon-1024 signed
  • Genesis Bootstrapping: Single agictl genesis command initializes Φ_C ≥ 0.72
  • ONNX Runtime Integration: Production-grade AI models with deepfake detection
  • Sovereign Package Management: Federated registry with IPFS caching

📊 Quality Gates

  • make verify: Zero errors, integrity chain intact
  • agictl audit --full: Clean audit ledger from genesis to tip
  • Codespace bootstrap: Running Cathedral in <10 minutes

🤝 Contributing

See CONTRIBUTING.md for development guidelines.

📄 License

Licensed under the Apache License, Version 2.0. See LICENSE for details.

🙏 Acknowledgments

Built upon the foundations of coherence, sovereignty, and collective emergence. "mcpServers": { "chrome-devtools": { "command": "npx", "args": ["-y", "chrome-devtools-mcp@latest"] } } }


### Local Development

1. **Install dependencies**:
   ```bash
   npm install --legacy-peer-deps
  1. Build the project:
    npm run build
  2. Start the dashboard:
    npm start

🛠️ Tools


Configuration

The Chrome DevTools MCP server supports the following configuration option:

  • --autoConnect/ --auto-connect If specified, automatically connects to a browser (Chrome 144+) running locally from the user data directory identified by the channel param (default channel is stable). Requires the remote debugging server to be started in the Chrome instance via chrome://inspect/#remote-debugging.

    • Type: boolean
    • Default: false
  • --browserUrl/ --browser-url, -u Connect to a running, debuggable Chrome instance (e.g. http://127.0.0.1:9222). For more details see: https://github.com/ChromeDevTools/chrome-devtools-mcp#connecting-to-a-running-chrome-instance.

    • Type: string
  • --wsEndpoint/ --ws-endpoint, -w WebSocket endpoint to connect to a running Chrome instance (e.g., ws://127.0.0.1:9222/devtools/browser/). Alternative to --browserUrl.

    • Type: string
  • --wsHeaders/ --ws-headers Custom headers for WebSocket connection in JSON format (e.g., '{"Authorization":"Bearer token"}'). Only works with --wsEndpoint.

    • Type: string
  • --headless Whether to run in headless (no UI) mode.

    • Type: boolean
    • Default: false
  • --executablePath/ --executable-path, -e Path to custom Chrome executable.

    • Type: string
  • --isolated If specified, creates a temporary user-data-dir that is automatically cleaned up after the browser is closed. Defaults to false.

    • Type: boolean
  • --userDataDir/ --user-data-dir Path to the user data directory for Chrome. Default is $HOME/.cache/chrome-devtools-mcp/chrome-profile$CHANNEL_SUFFIX_IF_NON_STABLE

    • Type: string
  • --channel Specify a different Chrome channel that should be used. The default is the stable channel version.

    • Type: string
    • Choices: stable, canary, beta, dev
  • --logFile/ --log-file Path to a file to write debug logs to. Set the env variable DEBUG to * to enable verbose logs. Useful for submitting bug reports.

    • Type: string
  • --viewport Initial viewport size for the Chrome instances started by the server. For example, 1280x720. In headless mode, max size is 3840x2160px.

    • Type: string
  • --proxyServer/ --proxy-server Proxy server configuration for Chrome passed as --proxy-server when launching the browser. See https://www.chromium.org/developers/design-documents/network-settings/ for details.

    • Type: string
  • --acceptInsecureCerts/ --accept-insecure-certs If enabled, ignores errors relative to self-signed and expired certificates. Use with caution.

    • Type: boolean
  • --experimentalVision/ --experimental-vision Whether to enable coordinate-based tools such as click_at(x,y). Usually requires a computer-use model able to produce accurate coordinates by looking at screenshots.

    • Type: boolean
  • --experimentalScreencast/ --experimental-screencast Exposes experimental screencast tools (requires ffmpeg). Install ffmpeg https://www.ffmpeg.org/download.html and ensure it is available in the MCP server PATH.

    • Type: boolean
  • --chromeArg/ --chrome-arg Additional arguments for Chrome. Only applies when Chrome is launched by chrome-devtools-mcp.

    • Type: array
  • --ignoreDefaultChromeArg/ --ignore-default-chrome-arg Explicitly disable default arguments for Chrome. Only applies when Chrome is launched by chrome-devtools-mcp.

    • Type: array
  • --categoryEmulation/ --category-emulation Set to false to exclude tools related to emulation.

    • Type: boolean
    • Default: true
  • --categoryPerformance/ --category-performance Set to false to exclude tools related to performance.

    • Type: boolean
    • Default: true
  • --categoryNetwork/ --category-network Set to false to exclude tools related to network.

    • Type: boolean
    • Default: true
  • --performanceCrux/ --performance-crux Set to false to disable sending URLs from performance traces to CrUX API to get field performance data.

    • Type: boolean
    • Default: true
  • --usageStatistics/ --usage-statistics Set to false to opt-out of usage statistics collection. Google collects usage data to improve the tool, handled under the Google Privacy Policy (https://policies.google.com/privacy). This is independent from Chrome browser metrics. Disabled if CHROME_DEVTOOLS_MCP_NO_USAGE_STATISTICS or CI env variables are set.

    • Type: boolean
    • Default: true
  • --slim Exposes a "slim" set of 3 tools covering navigation, script execution and screenshots only. Useful for basic browser tasks.

    • Type: boolean
  • --beeApi/ --bee-api Endpoint for Swarm Bee node (e.g., http://127.0.0.1:1633).

    • Type: string
    • Default: http://127.0.0.1:1633
  • --ipfsGateway/ --ipfs-gateway Endpoint for IPFS Gateway (e.g., http://127.0.0.1:8080).

    • Type: string
    • Default: http://127.0.0.1:8080
  • --ipfsApi/ --ipfs-api Endpoint for IPFS API (e.g., http://127.0.0.1:5001).

    • Type: string
    • Default: http://127.0.0.1:5001
  • --radicleHttpd/ --radicle-httpd Endpoint for Radicle httpd (e.g., http://127.0.0.1:8780).

    • Type: string
    • Default: http://127.0.0.1:8780
  • --ethRpc/ --eth-rpc Endpoint for Ethereum JSON-RPC (e.g., http://127.0.0.1:8545).

    • Type: string
    • Default: http://127.0.0.1:8545
  • --gridApiTokenId/ --grid-api-token-id API token ID for Lightspark Grid API.

    • Type: string
  • --gridApiClientSecret/ --grid-api-client-secret API client secret for Lightspark Grid API.

    • Type: string

Pass them via the args property in the JSON configuration. For example:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest",
        "--channel=canary",
        "--headless=true",
        "--isolated=true"
      ]
    }
  }
}

Connecting via WebSocket with custom headers

You can connect directly to a Chrome WebSocket endpoint and include custom headers (e.g., for authentication):

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest",
        "--wsEndpoint=ws://127.0.0.1:9222/devtools/browser/<id>",
        "--wsHeaders={\"Authorization\":\"Bearer YOUR_TOKEN\"}"
      ]
    }
  }
}

To get the WebSocket endpoint from a running Chrome instance, visit http://127.0.0.1:9222/json/version and look for the webSocketDebuggerUrl field.

You can also run npx chrome-devtools-mcp@latest --help to see all available configuration options.

Concepts

User data directory

chrome-devtools-mcp starts a Chrome's stable channel instance using the following user data directory:

  • Linux / macOS: $HOME/.cache/chrome-devtools-mcp/chrome-profile-$CHANNEL
  • Windows: %HOMEPATH%/.cache/chrome-devtools-mcp/chrome-profile-$CHANNEL

The user data directory is not cleared between runs and shared across all instances of chrome-devtools-mcp. Set the isolated option to true to use a temporary user data dir instead which will be cleared automatically after the browser is closed.

Connecting to a running Chrome instance

By default, the Chrome DevTools MCP server will start a new Chrome instance with a dedicated profile. This might not be ideal in all situations:

  • If you would like to maintain the same application state when alternating between manual site testing and agent-driven testing.
  • When the MCP needs to sign into a website. Some accounts may prevent sign-in when the browser is controlled via WebDriver (the default launch mechanism for the Chrome DevTools MCP server).
  • If you're running your LLM inside a sandboxed environment, but you would like to connect to a Chrome instance that runs outside the sandbox.

In these cases, start Chrome first and let the Chrome DevTools MCP server connect to it. There are two ways to do so:

  • Automatic connection (available in Chrome 144): best for sharing state between manual and agent-driven testing.
  • Manual connection via remote debugging port: best when running inside a sandboxed environment.

Automatically connecting to a running Chrome instance

Step 1: Set up remote debugging in Chrome

In Chrome (>= M144), do the following to set up remote debugging:

  1. Navigate to chrome://inspect/#remote-debugging to enable remote debugging.
  2. Follow the dialog UI to allow or disallow incoming debugging connections.

Step 2: Configure Chrome DevTools MCP server to automatically connect to a running Chrome Instance

To connect the chrome-devtools-mcp server to the running Chrome instance, use --autoConnect command line argument for the MCP server.

The following code snippet is an example configuration for gemini-cli:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": ["chrome-devtools-mcp@latest", "--autoConnect"]
    }
  }
}

Step 3: Test your setup

Make sure your browser is running. Open gemini-cli and run the following prompt:

Check the performance of https://developers.chrome.com

Note

The autoConnect option requires the user to start Chrome. If the user has multiple active profiles, the MCP server will connect to the default profile (as determined by Chrome). The MCP server has access to all open windows for the selected profile.

The Chrome DevTools MCP server will try to connect to your running Chrome instance. It shows a dialog asking for user permission.

Clicking Allow results in the Chrome DevTools MCP server opening developers.chrome.com and taking a performance trace.

Manual connection using port forwarding

You can connect to a running Chrome instance by using the --browser-url option. This is useful if you are running the MCP server in a sandboxed environment that does not allow starting a new Chrome instance.

Here is a step-by-step guide on how to connect to a running Chrome instance:

Step 1: Configure the MCP client

Add the --browser-url option to your MCP client configuration. The value of this option should be the URL of the running Chrome instance. http://127.0.0.1:9222 is a common default.

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest",
        "--browser-url=http://127.0.0.1:9222"
      ]
    }
  }
}

Step 2: Start the Chrome browser

Warning

Enabling the remote debugging port opens up a debugging port on the running browser instance. Any application on your machine can connect to this port and control the browser. Make sure that you are not browsing any sensitive websites while the debugging port is open.

Start the Chrome browser with the remote debugging port enabled. Make sure to close any running Chrome instances before starting a new one with the debugging port enabled. The port number you choose must be the same as the one you specified in the --browser-url option in your MCP client configuration.

For security reasons, Chrome requires you to use a non-default user data directory when enabling the remote debugging port. You can specify a custom directory using the --user-data-dir flag. This ensures that your regular browsing profile and data are not exposed to the debugging session.

macOS

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-profile-stable

Linux

/usr/bin/google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-profile-stable

Windows

"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222 --user-data-dir="%TEMP%\chrome-profile-stable"

Step 3: Test your setup

After configuring the MCP client and starting the Chrome browser, you can test your setup by running a simple prompt in your MCP client:

Check the performance of https://developers.chrome.com

Your MCP client should connect to the running Chrome instance and receive a performance report.

⚖️ Ethical Mandate (EQBE)

All modules related to simulation and quantum-biological state modification are subject to the Ethical Quantum-Biological Engineering (EQBE) protocol defined in AGENTS.md. This includes mandatory safety audits and adherence to non-disruption "Red Lines."


📝 Disclaimers

chrome-devtools-mcp exposes browser content to MCP clients. Avoid sharing sensitive information. Usage statistics are collected by default to improve performance (opt-out with --no-usage-statistics).

See Troubleshooting.


Installation Assistant

For a complete and automated installation of all components (Core, AI, Systems, and Simulator), use the Arkhe Setup Assistant:

python3 arkhe_setup_assistant.py

You can also run verification to ensure system coherence:

python3 arkhe_setup_assistant.py --verify

Repository Overview

This repository is a monorepo that integrates standard browser automation with the Arkhe(n) experimental framework.

Major Components

  • src/: Core TypeScript implementation of the MCP server, featuring standard DevTools tools and Arkhe-specific extensions.
  • arkhe-core/: Central networking and synchronization logic for the Arkhe PTST (Phase Topology Space-Time) nodes.
  • src/isa/: Definition of the Arkhé(n) Instruction Set Architecture (ISA) in Zig, governing low-level simulation opcodes.
  • arkhe-direnv/: A Go-based utility for managing coherent shell environments.
  • Mobile Integration: Native implementations for Android and iOS nodes located in android/ and ios/ directories.
  • Verification Suite: A collection of Python and TypeScript scripts in scripts/ for validating system coherence and security.

Ethical Mandate (EQBE)

Modules related to simulation and quantum-biological state modification are subject to the Ethical Quantum-Biological Engineering (EQBE) protocol defined in AGENTS.md. This includes mandatory safety audits and adherence to non-disruption "Red Lines."

For more details, consult the Quick Start Guide and the Implementation Summary.

About

ASI

Resources

License

Contributing

Security policy

Stars

Watchers

Forks

Packages

 
 
 

Contributors