Claude with a Browser: Building an Oracle APEX Dashboard with No Code

Building an Oracle APEX Dashboard Without Writing a Single Line of Code Myself

A follow-up to the OpenClaw autonomous agent post. This time: no Mac mini, no framework, no terminal. Just Claude, a Chrome extension, and a conversation that builds a fully functional Oracle APEX dashboard with live weather, crypto, news, maps, and market data.

The Simpler Path

In my last post, I walked through a fairly involved setup: a dedicated Mac mini, a macOS user account for the agent, OpenClaw as the orchestration framework, Slack for communication, soul files, heartbeats, cron jobs — the works. That setup is powerful. It gives you a 24/7 autonomous agent that can do things while you sleep.

But what if you don't want all that? What if you just want to sit down, have a conversation with an AI, and watch it build something in your browser — right now, on your machine, no infrastructure required?

That's exactly what I did this time. Anthropic recently released a Chrome extension for Claude that gives it the ability to see and interact with your browser. Pair that with a Claude Max subscription (which gives you access to Claude Opus 4), and you have something remarkable: an AI that can navigate web applications, click buttons, fill out forms, read pages, and execute JavaScript — all through your own Chrome browser, guided by a natural language conversation.

No servers. No framework. No dedicated machine. Just you, Claude, and a chat window.

What We Built

The result is Dashboard Hub — a fully functional, live-data dashboard built entirely inside Oracle APEX. It includes:

• Live Clock — real-time clock with date, updating every second
• Weather Widget — city search powered by the Open-Meteo API (no key required), showing temperature, humidity, wind speed, and "feels like"
• Cryptocurrency Tracker — top 6 coins by market cap via the CoinGecko API, with 24h price changes
• News Feed — latest headlines from Google News via RSS2JSON, showing source and time ago
• Market Overview — S&P 500, Dow Jones, NASDAQ, Gold, and EUR/USD
• Interactive World Map — powered by Leaflet.js and OpenStreetMap tiles, updates when you search a city in the weather widget
• Quick Info Panel — browser, screen resolution, language, platform, and online status
• Summary Cards — at-a-glance stats for temperature, Bitcoin, Ethereum, and timezone

All APIs are free and require no authentication keys. The entire dashboard runs client-side with JavaScript, fetching data on page load.

The Setup: Almost Nothing

Here's what you need:

That's it. You install the extension, open your APEX workspace, and start talking. Claude can see your screen, read the DOM, click elements, type into fields, and run JavaScript in the page context. It's like pair programming, except your partner has read every Stack Overflow answer ever written and doesn't need coffee breaks.

How the Conversation Went

I didn't write a spec. I didn't create wireframes. I literally said:

"Create a new APEX app that shows a dashboard, with newsfeed with the latest news from a real site API that is free, weather, crypto, stocks and all the good stuff you usually see in a dashboard, put a map, etc."

And Claude got to work.

Watch the app here: Dashboard-Hub

It started by navigating to the APEX App Builder, clicking "Create", typing "Dashboard Hub" as the application name, and creating the app. Then it opened Page 1 in the Page Designer, created a Static Content region, and started building.

The whole process was a back-and-forth. Not because Claude needed hand-holding, but because APEX's Page Designer is genuinely complex, and some approaches that seemed obvious turned out to have hidden limitations. Watching Claude navigate those obstacles in real-time was the most interesting part of the entire experiment.

The Real Story: How an AI Navigates APEX (and Why It Doesn't Follow Best Practices)

This is the part I want to be honest about, because I think it's the most valuable takeaway for anyone experimenting with AI-assisted development.

The AI doesn't know APEX best practices. And that's okay — for now.

If I were building this dashboard myself as an experienced APEX developer, I would do it very differently. I'd use native APEX components: Classic Reports or Cards regions backed by SQL queries, APEX charts for the crypto and market data, a Map region for the map, Template Components for the news cards, and page-level CSS/JS file references managed properly. I'd use Application Items and Application Processes for any server-side API calls. I'd probably use REST Data Sources to pull from the external APIs and bind them to report regions declaratively.

Claude did none of that.

Instead, it created a single Static Content region and stuffed the entire dashboard into it: HTML structure, CSS styles, and JavaScript — living together in one region's HTML Code field and the page-level "Execute when Page Loads" property. It's essentially a standalone single-page app that happens to be hosted inside an APEX page.

Why? Because Claude is drawing from general web development knowledge, not APEX-specific expertise. It knows HTML, CSS, and JavaScript extremely well. It knows how to fetch data from APIs, manipulate the DOM, and build responsive layouts. When I said "build a dashboard," it reached for the tools it knows best, and those tools happen to work inside a Static Content region.

From a pure APEX perspective, this is not how you'd do it. But from a "get a working prototype in 30 minutes using AI" perspective? It's incredibly effective.

The Static Content region: a pragmatic escape hatch

Here's the thing about APEX's Static Content region, it's both the simplest and the most flexible region type. It accepts raw HTML, and if you set the page-level JavaScript and CSS properties, you have a fully self-contained web application running inside the APEX framework. You get APEX's authentication, session management, navigation, and theming for free, while your content does whatever it wants inside the region body.

Is it the "APEX way"? No. Is it a valid approach for prototyping, proofs-of-concept, or dashboards that primarily consume external APIs? Absolutely.

Think of it like this, if APEX is a house, the Static Content region is a room where you're allowed to bring your own furniture. The house still provides the walls, the roof, and the plumbing (authentication, session, navigation). You're just decorating one room yourself.

The character limit discovery

One of the first real obstacles was Claude initially tried to type the full HTML+CSS+JavaScript code into the HTML Code editor using keyboard input. The APEX code editor (backed by Monaco) interpreted this as rapid keystrokes and duplicated content massively — the field ended up with over 227,000 characters. APEX threw an error, "Value too long by 195,106 characters!"

This is a scenario no human would encounter. You don't type 5,000 characters of code into a field letter by letter. You paste it. But Claude's type action simulates keystrokes, and Monaco's autocomplete and bracket-matching features turned a 5K block of code into a 227K mess.

How Claude adapted: It switched to using JavaScript to interact with Monaco directly — window.monaco.editor.getEditors()[0].setValue(code) — to set the content programmatically. When that still didn't persist changes to the APEX model, it discovered the pe object (APEX Page Designer's internal API) and used page.getProperty(id).setValue(value) to set properties directly through the model layer. This was a creative workaround that no documentation covers — Claude figured it out by inspecting the page's JavaScript objects in real-time.

APEX strips script tags from Static Content

Another surprise! APEX sanitizes the HTML Code field in Static Content regions. It strips <script> and <link> tags. This is a security feature — APEX doesn't want arbitrary scripts injected into regions because the same content could be edited by multiple developers.

Claude discovered this when the dashboard rendered the HTML and CSS, but none of the JavaScript executed. The solution: move JavaScript to the page-level "Execute when Page Loads" property (which is designed for JavaScript) and external library URLs to the page-level "JavaScript File URLs" and "CSS File URLs" properties.

This is actually the correct APEX pattern — page-level properties for JS/CSS, regions for HTML content. Claude arrived at the right answer, but through trial and error rather than prior knowledge.

The pe object: APEX's hidden internal API

This was the most fascinating part to watch. When clicking through the UI wasn't reliable enough for setting complex multi-line values, Claude started exploring the browser's JavaScript context. It found pe — the Page Designer's internal model object — and figured out how to:

• Start transactions: pe.transaction.start("name")
• Get components: pe.getComponents(pe.COMP_TYPE.PAGE)
• Set property values: component.getProperty(propertyId).setValue(value)
• Save changes: pe.saveChanges()

It even discovered property IDs by trial and error: 15 for JavaScript File URLs, 17 for Execute when Page Loads, 45 for CSS File URLs. These aren't documented anywhere publicly. Claude found them by reading the property panel's DOM elements and correlating them with the model's internal structure.

This is the kind of thing that makes you pause and think about what's actually happening. The AI is not following a tutorial. It's reverse-engineering a proprietary internal API in real-time to solve a problem it encountered organically.

What an APEX Expert Would Do Differently

In the interest of being educational, here's how I'd build this dashboard "the APEX way" and why Claude's approach is still valid for its context:

API Integration

APEX way: Create REST Data Sources for each API (Open-Meteo, CoinGecko, RSS2JSON). These are managed declaratively in Shared Components and can be bound to report regions, charts, or Template Components. Server-side calls mean no CORS issues and better error handling.

Claude's way: Client-side fetch() calls directly from the browser. This works because all the APIs chosen happen to support CORS and require no authentication. It's simpler, faster to implement, and perfectly fine for a dashboard, but wouldn't scale to APIs that require server-side secrets.

Layout

APEX way: Use APEX's grid layout system with multiple regions, each in its own column group. Use Template Options for responsive breakpoints. Use the Universal Theme's built-in card, badge, and report templates.

Claude's way: CSS Grid and Flexbox inside a single region, with custom CSS for the dark glassmorphism theme. This gives complete visual control but doesn't leverage APEX's theme roller or template system, meaning you lose the ability to change the application's look with a few clicks.

Map

APEX way: APEX has a native Map region (since version 21.2) that supports OpenStreetMap, Oracle Spatial, and GeoJSON. You can bind it to a SQL query, and it handles markers, layers, and interactivity declaratively.

Claude's way: Loaded Leaflet.js via CDN and initialized the map manually in JavaScript. This works and is actually more flexible (you can do anything Leaflet supports), but it's reinventing a wheel that APEX already has.

Charts and Data Visualization

APEX way: Oracle JET charts are built into APEX. You can create bar charts, line charts, pie charts — all backed by SQL queries, with interactive tooltips and responsive sizing.

Claude's way: Used styled HTML divs with color-coded text for positive/negative values. It looks good, but it's static visualization rather than interactive charts. Adding sparklines or trend charts would require a charting library.

The Key Insight

The AI chose the approach with the broadest applicability and lowest dependency on platform-specific knowledge. HTML, CSS, JavaScript, and fetch() work everywhere — in APEX, in a plain HTML file, in React, in any web context. APEX-specific components like REST Data Sources, Map regions, and JET Charts are more powerful within APEX but require knowledge that the AI doesn't have in depth.

This is a perfectly rational strategy. When you're uncertain about a platform's specific capabilities, you fall back to fundamentals. And web fundamentals are what Claude knows best.

The Chrome Extension Experience

A few observations on using Claude's Chrome extension for APEX development:

What works well:

• Reading the page — Claude can read the entire DOM, find elements, and understand page structure. It identified APEX's Page Designer components, the rendering tree, property panels, and code editors reliably.
• JavaScript execution — The ability to run JavaScript in the page context is a superpower. It's what enabled Claude to bypass UI limitations and interact with APEX's internal model directly.
• Navigating complex UIs — Claude handled APEX's multi-panel Page Designer surprisingly well, clicking into the rendering tree, right-clicking for context menus, and switching between layout tabs.
• Iterative problem-solving — When something didn't work, Claude could see the result, diagnose the issue, and try a different approach. The feedback loop is immediate and visual.

What's challenging:

• Monaco code editors — Typing code character-by-character into Monaco creates issues (autocomplete, bracket matching, and content duplication). The workaround (JavaScript setValue()) works, but isn't obvious.
• Complex drag-and-drop — APEX Page Designer uses drag and drop extensively. Claude can click and type, but complex drag operations to rearrange regions or move components between slots would be difficult.
• No persistent memory — Unlike the OpenClaw setup, Claude's Chrome extension doesn't have persistent memory between sessions. If you close the tab and come back, it doesn't remember what it built. The conversation context is the only thread of continuity.
• Speed — Browser automation is inherently slower than running SQL scripts directly. Each click, screenshot, and page read takes time. The OpenClaw approach of running wwv_flow_api.create_page_plug via SQL is faster for bulk operations.

When to Use Which Approach

The Chrome extension is the accessible option. Anyone with a Claude subscription can try it right now. No infrastructure, no configuration, no dedicated hardware. You open your browser and start talking.

The OpenClaw agent is the powerful option. It's for when you want the agent to work independently, on a schedule, with persistent memory and communication channels.

They're not competing approaches. They're different tools for different situations.

Reflections: What This Means for APEX Development

I've been building Oracle APEX applications for years. Watching an AI build one in real-time — making mistakes, discovering workarounds, and ultimately delivering a working product — has shifted how I think about the platform.

APEX's strength is also its challenge for AI. The Page Designer is incredibly powerful for human developers. It's visual, it's interactive, and it surfaces properties contextually. But those same qualities make it hard to automate. There's no CLI for APEX development (beyond SQLcl and the PL/SQL API). The Page Designer's internal model (pe) isn't documented for external use. Template IDs vary between workspaces. It's a platform built for human hands.

And Oracle knows this. That's exactly why APEXLang exists.

At APEXWorld 2025, Michael Hichwa (VP of Oracle APEX) demoed APEXLang — a domain-specific language and .apx file format that provides a human-readable, file-based definition of an entire APEX application. Unlike the traditional approach, where application metadata lives exclusively in the Oracle Database, APEXLang uses a formal grammar to define pages, regions, buttons, and everything else as plain text files. It integrates with SQLcl and SQL Developer, supports a compile/uncompile engine to sync files with the database, and — critically — is designed to be AI-friendly. Kris Rice from Oracle described it as "transformative for APEX."

This is the missing piece. Right now, when Claude builds an APEX app through the Chrome extension, it has to navigate a visual UI designed for human interaction, clicking through Page Designer, right-clicking for context menus, and reverse-engineering the pe internal API to set property values. It works, but it's fragile and slow. With APEXLang, an AI wouldn't need to touch the browser at all. It could generate .apx files directly — structured, version-controllable, diffable text — and compile them into a working application. That's not a workaround. That's a native development path.

APEXLang is part of Oracle's broader GenDev (Generative Development) initiative, which is weaving generative AI throughout APEX. APEX already has an AI Assistant that can generate application blueprints from plain English descriptions, write and refine SQL queries, author HTML/CSS/JavaScript/PL/SQL code, and even add conversational AI components to applications. GenDev is about shifting the developer's focus from the "how" to the "what" — describe what you want, and the platform builds it. APEXLang gives that vision a concrete file format that LLMs can produce, review, and iterate on.

Expected to arrive with APEX 25.1, APEXLang also opens the door to proper CI/CD workflows — .apx files in Git, code reviews through pull requests, automated linting, static analysis — things the APEX community has wanted for years. For AI agents specifically, it means the next version of this experiment won't need to navigate a UI at all. It'll generate .apx files, compile them via SQLcl, and the dashboard will just exist. No clicking, no pe hacks, no character limit surprises.

We're not there yet. But what we built today — an AI navigating the browser, reverse-engineering internal APIs, and shipping a working dashboard — is the bridge between where APEX is now and where APEXLang will take it.

The AI's "bad practices" are actually informative. When Claude chose to build an SPA inside a Static Content region instead of using native APEX components, it revealed something about the state of AI and specialized platforms. General-purpose AI models haven't been specifically trained on APEX development patterns. They don't know about REST Data Sources, Template Components, or the Map region. This gap will close over time — especially once APEXLang gives LLMs a structured, text-based format to learn from — but right now, the AI is operating like a talented web developer who's never used APEX before. And that's exactly what it is.

The prototype is the value, not the architecture. If I had asked a junior developer to build this dashboard, I'd review it and refactor. I'd replace the client-side fetches with REST Data Sources, swap the custom CSS for Theme Roller classes, and convert the hardcoded market data to a proper data source. That's a normal workflow. The AI gives you a working starting point in minutes instead of hours. The "proper APEX way" refactoring can come later, and now you have something concrete to refactor rather than a blank page.

Try It Yourself

1. Sign up for Oracle APEX free tier
2. Subscribe to Claude Max (Opus 4 access)
3. Install the Claude Chrome Extension
4. Navigate to your APEX App Builder
5. Tell Claude: "Build me a dashboard with weather, crypto, and news"
6. Watch it work

It won't be perfect. It won't follow every best practice. But in 30 minutes you'll have a working, live-data dashboard — and a much better understanding of what AI-assisted development actually looks like in practice.

Conclusion: The Democratization of "Just Build It"

The OpenClaw approach is for builders who want an autonomous teammate. The Chrome extension approach is for everyone else. Anyone who's ever stared at a blank APEX page and thought, "I know what I want, I just don't know how to get there."

Both approaches have the same fundamental insight. AI doesn't need to be an APEX expert to build something useful in APEX. It needs to be a good web developer — and that's exactly what modern language models are.

The gap between "AI that knows web development" and "AI that knows APEX development" is where the interesting work happens. It's where the AI improvises, adapts, and sometimes finds solutions that no human would think of (like reverse-engineering the pe internal API to bypass UI limitations).

That gap is also shrinking. Every time someone builds an APEX app with AI and shares the experience, the training data improves. The next model will know about REST Data Sources. The one after that will know about Template Components. Eventually, the AI won't need to fall back to a Static Content region because it'll know the "APEX way" as well as any senior developer.

But even today, with all its rough edges, an AI that can open your browser and build you a working dashboard from a single sentence is not the future. It's the present. And it's available to anyone with a Chrome extension and a subscription.

The future of development isn't about replacing the developer. It's about removing the gap between having an idea and seeing it run.

This is Part 2 of the "AI Agent Builds Oracle APEX" series. Part 1 covered the OpenClaw autonomous agent approach. Part 3 will explore using Claude to refactor the dashboard into proper APEX native components: REST Data Sources, Map regions, and Template Components.

Ready to Take Your Oracle Skills to the Next Level?

Go deeper with Marco's insights by gaining access to past webinar recordings, plus exclusive entry to upcoming members-only sessions through OraPub’s training community.

Check out Viscosity’s event page for upcoming virtual and on-site training opportunities.