When one company asked job applicants to submit a video where they answer a question, most of the 300 responses were "eerily similar," reports the Washington Post (with a company executive saying it was "abundantly clear" they'd used AI.) Job seekers are turning to AI to help them land jobs more quickly in a tough labor market.... Employers say that's having an unintended consequence: Many applications are looking and sounding the same... It's easy to spot when candidates over-rely on AI, some employers said. Oftentimes, executive summaries will look eerily similar to each other, odd phrases that people wouldn't normally use in conversation creep into descriptions, fancy vocabulary appears, and someone with entry-level experience uses language that indicates they are much more senior, they added. It's worse when they use auto-apply AI tools, which will find jobs, fill out applications and submit résumés on the candidate's behalf, some employers said. Those tend to misinterpret some of the application questions and fill in the wrong information in inappropriate spots. If these applications were evaluated alone, employers say they'd have a harder time identifying AI usage. But when hundreds of applications all have the same issue, they said, AI's role in it becomes obvious. The article acknowledges that some employers could be using AI tools to screen resumes too. One job-seeker in Texas even says he'll stop submitting an AI-written résumé when the recruiter stops using AI to evaluate them. "You're saying, 'You shouldn't be doing this' when I know a good chunk of them do this!" Obligatory XKCD.

Read more of this story at Slashdot.

This week Raspberry Pi saw its stock price surge more than 60% above its early-February low (before giving up some gains at the end of the week). Reuters notes the rise started when CEO Eben Upton bought 13,224 pounds worth of shares — but there could be another reason. "The rally in the roughly $800 million company has materialised alongside social-media buzz that demand for its single-board computers could pick up as people buy them to run AI agents such as OpenClaw." The Register explains: The catalyst appears to have been the sudden realization by one X user, "aleabitoreddit," that the agentic AI hand grenade known as OpenClaw could drive demand for Raspberry Pis the way it had for Apple Mac Minis. The viral AI personal assistant, formerly known as Clawdbot and Moltbot, has dominated the feeds of AI boosters over the past few weeks for its ability to perform everyday tasks like sending emails, managing calendars, booking appointments, and complaining about their meatbag masters on the purportedly all-agent forum known as MoltBook... In case it needs to be said, no one should be running this thing on their personal devices lest the agent accidentally leak your most personal and sensitive secrets to the web... In this context, a cheap low-power device like a Raspberry Pi makes a certain kind of sense as a safer, saner way to poke the robo-lobster... The Register argues Raspberry Pis aren't as cheap as they used to be "thanks in part to the global memory crunch. Today, a top-specced Raspberry Pi 5 with 16GB of memory will set you back more than $200, up from $120 a year ago." "You know what's cheaper, easier, and more secure than letting OpenClaw loose on your local area network? A virtual private cloud..."

Read more of this story at Slashdot.

I'm giving a presentation at Louisiana Tech University on March 30, 2026, on what I'm calling the cyborg model of technical writing. The tldr is that I feel the emerging model for tech writing isn't one in which AI replaces tech writers; instead, it's one in which AI augments tech writers. Tech writers interact with AI in a continuous back-and-forth, iterative process, representing the cyborg model.

How to Troubleshoot Azure Functions Not Visible in Azure Portal

Overview

Azure Functions is a powerful serverless compute service that enables you to run event-driven code without managing infrastructure. When you deploy functions to Azure, you expect to see them listed in the Azure Portal under your Function App. However, there are situations where your functions may not appear in the portal, even though they were successfully deployed.

This issue can be frustrating, especially when your functions are actually running and processing requests correctly, but you cannot see them in the portal UI. In this blog, we will explore the common causes of functions not appearing in the Azure Portal and provide step-by-step solutions to help you troubleshoot and resolve this issue.

Understanding How Functions Appear in the Portal

Before diving into troubleshooting, it's important to understand how the Azure Portal discovers and displays your functions.

Function Visibility Process

When you open a Function App in the Azure Portal, the following process occurs:

1. Host Status Check: The portal queries your Function App's host status endpoint (/admin/host/status)
2. Function Enumeration: The portal requests a list of functions from the Functions runtime
3. Metadata Retrieval: For each function, the portal retrieves metadata including trigger type, bindings, and configuration
4. UI Rendering: The portal displays the functions in the Functions blade

If any step in this process fails, your functions may not appear in the portal.

Key Files for Function Discovery

Visibility Issue Categories

Common Causes and Solutions

1. Function App Host Is Not Running

Symptoms:

• No functions visible in the portal
• "Function host is not running" error message
• Host status shows "Error" or no response

Why This Happens:

The Functions host must be running for the portal to discover functions. If the host fails to start, functions won't be visible.

How to Verify:

You can check the host status using the following URL: Function API

https://<your-function-app>.azurewebsites.net/admin/host/status?code=<master-key>

Expected healthy response:

{ "state": "Running" }

Solution:

1. Navigate to your Function App in the Azure Portal
2. Go to Diagnose and solve problems
3. Search for "Function App Down or reporting", "Function app startup issue"
4. Review the diagnostics for startup errors

Common fixes:

• Check Application Settings for missing or incorrect values
• Verify AzureWebJobsStorage connection string is valid
• Ensure FUNCTIONS_EXTENSION_VERSION is set correctly (e.g., ~4)
• Check for missing extension bundles in host.json

2. Deployment Issues

Symptoms:

• Functions visible locally but not in portal after deployment
• Only some functions appear
• Old versions of functions showing

Why This Happens:

Deployment problems can result in incomplete or corrupted deployments where function files are missing or incorrectly placed.

How to Verify:

The verification method depends on your hosting plan:

For Windows plans (Consumption, Premium, Dedicated) - Use Kudu:

1. Navigate to Development Tools → Advanced Tools (Kudu)
2. Go to Debug console → CMD or PowerShell
3. Navigate to site/wwwroot
4. Verify your function folders and files exist

Kudu is not available for Linux Consumption and Flex Consumption plans. Use alternatives such as SSH or Azure CLI instead. refer Deployment technologies in Azure Functions

For compiled languages (C#, F#), verify:

site/wwwroot/ ├── host.json ├── bin/ │ ├── <YourAssembly>.dll │ └── extensions.json └── function1/ └── function.json

 

Similarly for script languages (JavaScript, Python, PowerShell), verify:

Python Folder Structure

PowerShell Folder structure

NodeJS Folder structure

Solution:

• Redeploy your function app using your preferred method:
  • Visual Studio / VS Code
  • Azure CLI
  • GitHub Actions / Azure DevOps
  • Kudu ZIP deploy
• Clear the deployment cache: Restart your function app through Portal or CLI/PowerShell

        # Using Azure CLI az functionapp restart    

az functionapp restart --name <app-name> --resource-group <resource-group>

3. Invalid or Missing function.json

Symptoms:

• Specific functions not appearing
• Some functions visible, others missing
• Function appears but shows wrong trigger type

Why This Happens:

Each function requires a valid function.json file (generated at build time for compiled languages, or manually created for script languages). If this file is missing, malformed, or contains errors, the function won't be discovered.

Example of Valid function.json for http trigger:

{ "bindings": [ { "authLevel": "function", "type": "httpTrigger", "direction": "in", "name": "req", "methods": ["get", "post"] }, { "type": "http", "direction": "out", "name": "$return" } ] }

 

Common function.json Errors:

Solution:

1. Check the function folder in Kudu for function.json
2. Validate the JSON syntax using a JSON validator
3. For compiled functions, ensure your project builds successfully
4. Check build output for warnings about function metadata

4. V2 Programming Model Issues (Python/Node.js)

Symptoms:

• Using Python v2 or Node.js v4 programming model
• Functions defined in code but not visible in portal
• No function.json files in function folders

Why This Happens:

The V2 programming model for Python and v4 model for Node.js define functions using decorators/code instead of function.json files. The portal requires the host to be running to discover these functions dynamically.

Python V2 Example:

import azure.functions as func import logging app = func.FunctionApp() @app.function_name(name="HttpTrigger1") @app.route(route="hello", auth_level=func.AuthLevel.FUNCTION) def hello(req: func.HttpRequest) -> func.HttpResponse: logging.info('Python HTTP trigger function processed a request.') return func.HttpResponse("Hello!")

Node.js V4 Example:

const { app } = require('@azure/functions'); app.http('HttpTrigger1', { methods: ['GET', 'POST'], authLevel: 'function', handler: async (request, context) => { context.log('HTTP trigger function processed a request.'); return { body: 'Hello!' }; } });

Solution:

1. Verify the host is running (see Solution #1)
2. Check your entry point configuration.
3. Check Application Insights for host startup errors related to function registration
4. Check folder structure - Python folder structure

5. Extension Bundle or Dependencies Missing

Symptoms:

• Functions not appearing after adding new trigger types
• Host fails to start with extension-related errors
• Works locally but not in Azure

Why This Happens:

Azure Functions uses extension bundles to provide trigger and binding implementations. If the bundle is missing or incorrectly configured, functions using those triggers won't work.

How to Verify:

Check your host.json for extension bundle configuration: extension bundle

{ "version": "2.0", "extensionBundle": { "id": "Microsoft.Azure.Functions.ExtensionBundle", "version": "[4.*, 5.0.0)" } }

Solution:

1. Ensure extension bundle is configured in host.json
2. Use a compatible version range:
   • For Functions v4: [4.*, 5.0.0)
3. For compiled C# apps using explicit extensions, ensure all NuGet packages are installed:
4. Check for extension installation errors and fix it

6. Sync Trigger Issues

Symptoms:

• Functions deployed successfully
• Host is running
• Portal still shows no functions or outdated function list

Why This Happens:

The Azure Portal caches function metadata. Sometimes this cache becomes stale or the sync process between the function host and the portal fails.

Solution:

1. Force a sync from the portal:
   • Navigate to your Function App
   • Click Refresh button in the Functions blade
   • If that doesn't work, go to Overview → Restart
2. Trigger a sync via REST API:
   1. Sync Trigger
   2. az rest --method post --url https://management.azure.com/subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.Web/sites/<APP_NAME>/syncfunctiontriggers?api-version=2016-08-01

7. Storage Account Connectivity Issues

Symptoms:

• Functions not visible
• Host shows errors related to storage
• "Unable to get function keys" error

Why This Happens:

Azure Functions requires access to the storage account specified in AzureWebJobsStorage for:

• Storing function keys and secrets
• Coordinating distributed triggers
• Maintaining internal state

If the function app cannot connect to storage, the host may fail to start properly.

How to Verify:

Check the Application Settings: Storage considerations for Azure Functions

• AzureWebJobsStorage - Must be a valid connection string
• WEBSITE_CONTENTAZUREFILECONNECTIONSTRING - For Consumption/Premium plans
• WEBSITE_CONTENTSHARE - File share name

Solution:

1. Verify the storage account exists and is accessible
2. Check for firewall rules on the storage account:
   • Go to Storage Account → Networking
   • Ensure Function App has access (public endpoint or VNet integration)
3. Regenerate connection strings if storage keys were rotated:
   • Get new connection string from storage account
   • Update AzureWebJobsStorage in Function App settings
4. For VNet-integrated apps, ensure:
   • Service endpoints or private endpoints are configured
   • DNS resolution works for storage endpoints

Check for more details - Storage considerations for Azure Functions

8. WEBSITE_RUN_FROM_PACKAGE Issues

Symptoms:

• Functions not visible after deployment
• Functions were visible before but disappeared
• "No functions found" in the portal
• Read-only file system errors in logs

Why This Happens:

When WEBSITE_RUN_FROM_PACKAGE is configured, Azure Functions runs directly from a deployment package (ZIP file) instead of extracting files to wwwroot. If the package is inaccessible, corrupted, or misconfigured, the host cannot load your functions.

Understanding WEBSITE_RUN_FROM_PACKAGE Values:

How to Verify:

1. Check the app setting value.
2. If using URL, verify package accessibility.
3. Check if package exists properly (when value is 1):
   • Go to Kudu → Debug Console
   • Navigate to d:\home\data\SitePackages
   • Verify a .zip file exists and packagename.txt points to it
4. Verify package contents:
   • Download the package
   • Extract and verify host.json and function files are present at the root level (not in a subfolder)

Common Issues:

9. Configuration Filtering Functions

Symptoms:

• Only some functions visible
• Specific functions always missing
• Functions worked before a configuration change

Why This Happens:

Azure Functions provides configuration options to filter which functions are loaded. If these are misconfigured, functions may be excluded.

Configuration Options to Check:

1. host.json functions array: Host.json -> functions

{ "functions": ["Function1", "Function2"] }

Solution:

1. Remove the functions array from host.json (or ensure all desired functions are listed)

10. Networking Configuration Issues

Symptoms:

• Functions not visible in portal but app responds to requests
• "Unable to reach your function app" error in portal
• Portal timeout when loading functions
• Functions visible intermittently
• Host status endpoint not reachable from portal

Why This Happens:

When your Function App has networking restrictions configured (VNet integration, private endpoints, access restrictions), the Azure Portal may not be able to communicate with your function app to discover and display functions. The portal needs to reach your app's admin endpoints to enumerate functions.

Common Networking Configurations That Cause Issues:

 

Important Note:

When your Function App is fully private (no public access), you won't be able to see functions in the Azure Portal from outside your network. This is expected behavior.

Using Diagnose and Solve Problems

The Azure Portal provides built-in diagnostics to help troubleshoot function visibility issues.

How to Access:

1. Navigate to your Function App in the Azure Portal
2. Select Diagnose and solve problems from the left menu
3. Search for relevant detectors:

   • Function App Down or Reporting Errors

   • SyncTrigger Issues
   • Deployment
   • Networking

Quick Troubleshooting Checklist

Use this checklist to quickly diagnose functions not appearing in the portal:

• Host Status: Is the host running? Check /admin/host/status
• Files Present: Are function files deployed? Check via Kudu
• function.json Valid: Is the JSON syntax correct?
• Run From Package: If using WEBSITE_RUN_FROM_PACKAGE, is package accessible and configured right?
• Extension Bundle: Is extensionBundle properly configured in host.json?
• Storage Connection: Is AzureWebJobsStorage valid and reachable?
• No Filters: Is functions array in host.json filtering?
• V2 Model: For Python/Node.js v2, is host running to register?
• Sync Triggered: Has the portal synced with the host?
• Networking: Can the portal reach the app? Check access restrictions/private endpoints

Verifying Functions via REST API

If you cannot see functions in the portal but believe they're deployed, you can verify directly: Functions API

List All Functions:

curl "https://<app>.azurewebsites.net/admin/functions?code=<master-key>"

 

Or directly from here with auth: List Functions

 

Check Specific Function:

curl "https://<app>.azurewebsites.net/admin/functions/<function-name>?code=<master-key>"

Get Host Status:

curl "https://<app>.azurewebsites.net/admin/host/status?code=<master-key>"

If these APIs return your functions but the portal doesn't show them, the issue is likely a portal caching/sync problem (see Solution #6).

Conclusion

Functions not appearing in the Azure Portal can be caused by various issues, from deployment problems to configuration filtering. By following the troubleshooting steps outlined in this article, you should be able to identify and resolve the issue.

Key Takeaways:

1. Always verify the host is running first
2. Check that function files are correctly deployed
3. Validate function.json and host.json configurations
4. Ensure storage connectivity is working
5. Use the built-in diagnostics in the Azure Portal
6. Force a sync if functions are deployed but not visible

If you continue to experience issues after following these steps, consider opening a support ticket with Microsoft Azure Support, providing:

• Function App name and resource group
• Steps to reproduce the issue
• Any error messages observed
• Recent deployment or configuration changes

References

• Azure Functions host.json reference
• Azure Functions deployment technologies
• Troubleshoot Azure Functions
• Python V2 programming model
• Node.js V4 programming model
• Azure Functions diagnostics
• Azure Functions networking options

Have questions or feedback? Leave a comment below.

Step 1: Deploying Models on Microsoft Foundry

Let us kick things off in the Azure portal. To get our OpenClaw agent thinking like a genius, we need to deploy our models in Microsoft Foundry. For this guide, we are going to focus on deploying gpt-5.2-codex on Microsoft Foundry with OpenClaw. 

Navigate to your AI Hub, head over to the model catalog, choose the model you wish to use with OpenClaw and hit deploy. Once your deployment is successful, head to the endpoints section.

 

Important: Grab your Endpoint URL and your API Keys right now and save them in a secure note. We will need these exact values to connect OpenClaw in a few minutes.

Step 2: Installing and Initializing OpenClaw

Next up, we need to get OpenClaw running on your machine. Open up your terminal and run the official installation script:

curl -fsSL https://openclaw.ai/install.sh | bash

The wizard will walk you through a few prompts. Here is exactly how to answer them to link up with our Azure setup:

• First Page (Model Selection): Choose "Skip for now".
  
  

   

• Second Page (Provider): Select azure-openai-responses.
  
  

 

• Model Selection: Select gpt-5.2-codex , For now only the models listed (hosted on Microsoft Foundry) in the picture below are available to be used with OpenClaw.
  
• Follow the rest of the standard prompts to finish the initial setup.
  
  

Step 3: Editing the OpenClaw Configuration File

Now for the fun part. We need to manually configure OpenClaw to talk to Microsoft Foundry. Open your configuration file located at ~/.openclaw/openclaw.json in your favorite text editor.

Replace the contents of the models and agents sections with the following code block:

{ "models": { "providers": { "azure-openai-responses": { "baseUrl": "https://<YOUR_RESOURCE_NAME>.openai.azure.com/openai/v1", "apiKey": "<YOUR_AZURE_OPENAI_API_KEY>", "api": "openai-responses", "authHeader": false, "headers": { "api-key": "<YOUR_AZURE_OPENAI_API_KEY>" }, "models": [ { "id": "gpt-5.2-codex", "name": "GPT-5.2-Codex (Azure)", "reasoning": true, "input": ["text", "image"], "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 }, "contextWindow": 400000, "maxTokens": 16384, "compat": { "supportsStore": false } }, { "id": "gpt-5.2", "name": "GPT-5.2 (Azure)", "reasoning": false, "input": ["text", "image"], "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 }, "contextWindow": 272000, "maxTokens": 16384, "compat": { "supportsStore": false } } ] } } }, "agents": { "defaults": { "model": { "primary": "azure-openai-responses/gpt-5.2-codex" }, "models": { "azure-openai-responses/gpt-5.2-codex": {} }, "workspace": "/home/<USERNAME>/.openclaw/workspace", "compaction": { "mode": "safeguard" }, "maxConcurrent": 4, "subagents": { "maxConcurrent": 8 } } } }

 

You will notice a few placeholders in that JSON. Here is exactly what you need to swap out:

 

Step 4: Restart the Gateway

After saving the configuration file, you must restart the OpenClaw gateway for the new Foundry settings to take effect. Run this simple command:

openclaw gateway restart

Configuration Notes & Deep Dive

If you are curious about why we configured the JSON that way, here is a quick breakdown of the technical details.

Authentication Differences Azure OpenAI uses the api-key HTTP header for authentication. This is entirely different from the standard OpenAI Authorization: Bearer header. Our configuration file addresses this in two ways:

• Setting "authHeader": false completely disables the default Bearer header.
• Adding "headers": { "api-key": "<key>" } forces OpenClaw to send the API key via Azure's native header format.

Important Note: Your API key must appear in both the apiKey field AND the headers.api-key field within the JSON for this to work correctly.

The Base URL Azure OpenAI's v1-compatible endpoint follows this specific format: https://<your_resource_name>.openai.azure.com/openai/v1

The beautiful thing about this v1 endpoint is that it is largely compatible with the standard OpenAI API and does not require you to manually pass an api-version query parameter.

Model Compatibility Settings

• "compat": { "supportsStore": false } disables the store parameter since Azure OpenAI does not currently support it.
• "reasoning": true enables the thinking mode for GPT-5.2-Codex. This supports low, medium, high, and xhigh levels.
• "reasoning": false is set for GPT-5.2 because it is a standard, non-reasoning model.

Model Specifications & Cost Tracking

If you want OpenClaw to accurately track your token usage costs, you can update the cost fields from 0 to the current Azure pricing. Here are the specs and costs for the models we just deployed:

Model Specifications

 

Current Cost (Adjust in JSON)

 

Conclusion:

And there you have it! You have successfully bridged the gap between the enterprise-grade infrastructure of Microsoft Foundry and the local autonomy of OpenClaw. By following these steps, you are not just running a chatbot; you are running a sophisticated agent capable of reasoning, coding, and executing tasks with the full power of GPT-5.2-codex behind it.

The combination of Azure's reliability and OpenClaw's flexibility opens up a world of possibilities. Whether you are building an automated devops assistant, a research agent, or just exploring the bleeding edge of AI, you now have a robust foundation to build upon.

Now it is time to let your agent loose on some real tasks. Go forth, experiment with different system prompts, and see what you can build. If you run into any interesting edge cases or come up with a unique configuration, let me know in the comments below. Happy coding!

On this episode we dive into Tiny Tool Town — a GeoCities‑style app hub for tiny developer utilities — and James walks us through building Tiny Clips, a Mac toolbar screen‑capture app he prototyped and shipped using Copilot, agentic workflows, and a plan‑implement‑review cycle. Expect practical takeaways on multi‑model AI pipelines (planning with 5.2, coding with Codex/Opus), CI/publishing tips, sandboxing/TestFlight pitfalls, and why tiny apps are booming.

Follow Us

• Frank: Twitter, Blog, GitHub
• James: Twitter, Blog, GitHub
• Merge Conflict: Twitter, Facebook, Website, Chat on Discord
• Music : Amethyst Seer - Citrine by Adventureface

⭐⭐ Review Us ⭐⭐

Machine transcription available on http://mergeconflict.fm

Support Merge Conflict

Links:

• Tiny Tool Town
• Tiny Clips

Download audio: https://aphid.fireside.fm/d/1437767933/02d84890-e58d-43eb-ab4c-26bcc8524289/b6d3406b-896f-4165-8b2b-ae41a248224e.mp3