|
Sr. Content Developer at Microsoft, working remotely in PA, TechBash conference organizer, former Microsoft MVP, Husband, Dad and Geek.
|
Welcome to GitHub Copilot CLI for Beginners! In this series (available in video and blog format), we’ll give you everything you need to get started using GitHub Copilot CLI, from your first prompt to tips for navigating the command line like a pro!
In this blog, we’ll cover the two main modes of the CLI: interactive and non-interactive. You’ll learn the differences between the two modes, how to enter them, and what they’re most useful for.
Let’s dive in!
Interactive mode is a back-and-forth, chat-like experience. When you launch Copilot CLI with Copilot, you’re already in interactive mode—that’s the default. Non-interactive mode is a separate option for when you want a quick, one-off answer without entering a session. (More on non-interactive mode later!)
In interactive mode, you can ask GitHub Copilot a question, review its response, and then either follow up with questions or another prompt—all within the same session. This is the mode for those who want to work hands-on with Copilot and iterate as you go.
Here’s how to enter interactive mode:
Log in
copilot and hit Enter.On the other hand, non-interactive mode is designed for speed and simplicity. Instead of having to enter a full session, you pass a single prompt right in the command line and get a response almost immediately, without needing to follow up with Copilot.
Designed as an in-line experience, this mode is perfect for quick, one-shot prompts like summarizing a repository, generating code snippets, or plugging Copilot into automated workflows, without leaving your shell context. Once you get an answer, you’re right back in your terminal flow.
Here’s how to enter non-interactive mode:
copilot -p and prompt the agent with something like “Quickly summarize what this repository does and the key folders.”Together, these two modes help you tackle all kinds of projects efficiently: interactive for explorative, deeper work, and non-interactive for fast, focused results when you already know exactly what you need.
Sometimes, you may want to pick up right where you left off in a previous Copilot session, while retaining all the context from that conversation.
If you’re in interactive mode, you can type /resume into the command line and Copilot will let you choose a previous session from a list. If you want to launch directly into the previous session picker from non-interactive mode, use copilot --resume.
It only takes one command to pick back up with Copilot, which is super useful if you already know what session you want to work in.
Take this with you GitHub Copilot CLI interactive and non-interactive modes are the fastest ways to prompt Copilot directly from your terminal. Having the option to pick between back-and-forth coding and quick prompting means you can work with Copilot, the way you want.
Keep an eye out for more videos in the GitHub Copilot CLI for Beginners series, where we’ll explore:
Happy coding!
Looking to try GitHub Copilot CLI? Read the Docs and get started today.
The post GitHub Copilot CLI for Beginners: Interactive v. non-interactive mode appeared first on The GitHub Blog.
At Microsoft, security innovations are purpose-built to help every organization protect end-to-end with the speed and scale of AI. Our vision is simple: security should be ambient and autonomous, just like the AI it protects.
In a world where AI agents can act autonomously to take action, access data, and interact across systems, every organization should have the confidence that their security posture can scale and keep pace with their AI investments. Microsoft is focused on helping organizations gain visibility into what their agents are doing, governance over what they’re allowed to do, and protection against emerging threats. With an AI-first, end-to-end security platform grounded in Zero Trust for AI, fueled by more than 100 trillion daily threat signals1, and shaped by the Secure Future Initiative, security and IT teams can harden their security posture with protection that is continuous, intelligent, and built for the agentic era.
In the Loop is a new series from Microsoft Security that delivers timely news and updates to the global security community. Today’s edition spotlights the latest capabilities designed to help security and IT teams secure their AI agents, secure their foundations, and defend against threats in real time with the powerful combination of agents and experts.
The Agent 365 tooling gateway gives security teams the visibility and control they need to detect and respond to threats that target agentic workflows. New Microsoft Defender capabilities, now available in preview, enable security teams to detect, block and investigate anomalous behavior of their agents. Near real-time protection leverages webhooks to evaluate the actions an AI agent attempts to detect and block malicious or risky activities before they’re executed. Read more and get started.
Microsoft Defender for Cloud integration with GitHub Advanced Security, now generally available, provides unified security visibility across the development lifecycle. This integration automatically maps code changes to production environments, prioritizes security alerts based on real runtime context, and enables coordinated remediation workflows between development and security teams. Teams can track vulnerabilities from source code to deployed applications, focus on the security issues that affect production workloads, and take advantage of AI-powered remediation tools to speed resolution.2 Get started today and watch the video.
Step into the role of a data security analyst and see how Microsoft Purview Data Security Investigations helps you identify investigation‑relevant data, analyze it using AI‑powered deep content analysis, and mitigate sensitive data risks—all within a single, integrated solution. Follow the end‑to‑end investigation journey in this hands‑on demo.
In the demo, you’ll learn how to:
Microsoft Security continually ships meaningful innovations across our portfolio and research-driven insights and reports for the security community. In the Loop posts are your reliable source of what’s new across Microsoft Security and what it means for your security strategy. Check back for the next drop and connect with us at Microsoft Build, June 2-3, 2026 in San Francisco, to hear directly from Microsoft Security experts, learn more about today’s releases, and more.
To learn more about Microsoft Security solutions, visit our website. Bookmark the Security blog to keep up with our expert coverage on security matters. Also, follow us on LinkedIn (Microsoft Security) and X (@MSFTSecurity) for the latest news and updates on cybersecurity.
1Microsoft Digital Defense Report 2025, Safeguarding Trust in the AI Era
2GitHub Advanced Security Integration with Microsoft Defender for Cloud, Microsoft Defender for Cloud | Microsoft Learn
The post What’s new, updated, or recently released in Microsoft Security appeared first on Microsoft Security Blog.
Windows Server powers critical workloads worldwide—but the operational bar keeps rising. Security events demand faster patch-to-protect cycles, resiliency expectations leave less room for maintenance windows, and hybrid footprints make it harder to standardize how servers are configured, monitored, and governed across environments.
In practice, many teams are working through the same set of questions: How do we meet tighter patch service level agreements (SLAs) without increasing risk? How do we reduce configuration drift as companies scale? And how do we apply consistent operational standards—whether a server is on premises, in Azure, or deployed at the edge?
Hear firsthand from our engineering and product teams as they focus on delivering practical implementation and guidance across security, patching, resiliency, and hybrid operations.
Join us at the Windows Server Summit 2026 on May 11–13 to explore how we can tackle these challenges. Hear firsthand from our engineering and product teams as they focus on delivering practical implementation and guidance across security, patching, resiliency, and hybrid operations.
Following strong engagement in 2025, Windows Server Summit 2026 has been fine‑tuned based on what customers have consistently asked for: practical, engineering‑led guidance that focuses on operating Windows Server efficiently at scale.
Over three days, Microsoft engineers and product leaders will share scenario-based technical sessions and actionable guidance you can use to strengthen security, simplify operations, and modernize your Windows Server estate at your own pace.
Across the customer base, we’re observing a consistent shift in operational priorities—away from evaluating new features in isolation and toward understanding how capabilities inform day‑to‑day operating decisions. Here are a few areas where teams are investing time in 2026, and the implementation questions they’re trying to answer:
Many organizations are aligning upgrade timelines with operational goals—reducing risk, standardizing images and baselines, and limiting downtime. Common planning decisions include where hotpatching fits into the rollout strategy, how to phase upgrades across tiers of criticality, and how to validate compatibility and performance without slowing delivery.
As footprints spread across locations, teams are prioritizing a single operational model for inventory, policy, and access control. A frequent focus is hybrid management with Azure Arc—using consistent tooling to apply governance, track compliance, and reduce fragmented administrative approaches that result from environment or team‑specific server management practices.
When estates grow, “known good” configurations can diverge quickly—especially across mixed hardware, virtualization stacks, and hybrid deployments. Teams are investing in repeatable baselines, clear alerting and monitoring standards, and drift detection so that operational posture doesn’t depend on individual server histories. In parallel, many are tightening patch SLAs and expanding automation (including hotpatching where applicable) to reduce exposure time while keeping change control predictable.
Windows Server Summit 2026 offers an early opportunity to engage with what’s next for Windows Server—giving you a preview of where we’re headed and the challenges we’re addressing before plans are formally set.
Just as important, the Summit creates space for a two‑way conversation. Each session will feature live Q and A, giving you the opportunity to get answers to your questions—and share feedback directly with the product team, helping shape future investments based on what matters most in your environment.
Throughout the Summit, you can expect guidance that’s intended to be immediately useful—not theoretical. Topics include:
Our aim is to connect individual features to your broader operational strategy—enabling you to decide what to act on today, what to standardize across environments, and what to plan for in the upcoming release cycle.
These modernization themes tend to become urgent when something changes in your environment—new security requirements, tighter uptime expectations, or a growing hybrid estate. A few common triggers we’re hearing from organizations include:
Designed for enterprise IT professionals, architects, and decision-makers, Windows Server Summit 2026 focuses on scenario-driven guidance to help teams secure, modernize, and extend Windows Server environments—on premises, in Azure, and across hybrid infrastructure.
If you’re looking for more in‑depth implementation guidance and engineering context, join us at Windows Server Summit 2026, May 11–13, to explore these topics further.
The post Planning your path to Windows Server 2025: What organizations are prioritizing in 2026 appeared first on Microsoft Windows Server Blog.
The Azure Developer CLI (azd) shipped five releases in April 2026. The biggest theme this month is multi-language hook support: write azd hooks in Python, JavaScript, TypeScript, or .NET alongside the existing Bash and PowerShell options. Here’s what’s in versions 1.23.14, 1.23.15, 1.24.0, 1.24.1, and 1.24.2.
To share your feedback and questions, join the April release discussion on GitHub.
Highlights:
azd update graduates to public preview, so you can update with a single command on any platform--no-prompt behavior for reliable automation in CI/CD pipelines and AI agents
Multi-language hooksHooks in azure.yaml now support Python, JavaScript, TypeScript, and .NET scripts, alongside the existing Bash and PowerShell options. Each language gets automatic dependency installation and runtime management. Read more in Write azd hooks in Python, JavaScript, TypeScript, or .NET.
.py script and azd detects it automatically. When requirements.txt or pyproject.toml is present, a virtual environment is created and dependencies are installed before execution. [#7451].js or .ts script for automatic detection. When package.json is present, azd runs npm install first. TypeScript scripts execute through npx tsx with no compile step required. [#7626].cs file and azd executes it with dotnet run, with automatic project discovery and support for single-file scripts on .NET 10+. [#7652]config: block for hooks in azure.yaml lets you configure packageManager for JavaScript/TypeScript hooks, virtualEnvName for Python hooks, and configuration/framework for .NET hooks. [#7690]infra.layers[].hooks now execute during azd provision, and azd hooks run supports a new --layer flag for targeted execution. [#7382]
Extension FrameworkThe Extension Framework (currently in Beta, while azd itself is GA) gains new capabilities for extension authors and a smoother upgrade experience for users.
WithProvisioningProvider("name", factory) on the ExtensionHost. Users set infra: { provider: name } in azure.yaml to use them. [#7482]azd extension upgrade now resolves the installed source by default, automatically promotes extensions from a dev registry to the main registry when a newer version is available, and processes --all or --no-prompt batch upgrades non-interactively. [#7841]@Microsoft.KeyVault(...) references in environment variables before passing them to extensions. [#7043]
AI and Copilotazd provision now detects Azure Cognitive Services model deployments in the Bicep snapshot and validates quota availability before provisioning, warning on exceeded quota or unrecognized model names. [#7672]PromptLocation extension framework API adds an allowed_locations filter, and AI model capacity resolution falls back to the highest valid capacity within remaining quota. [#7397]
Project setup and initialization.azdignore for templates: Template authors can create a .azdignore file in the template root to exclude contributor-only files (such as SECURITY.md, .github/) from being copied to consumer projects. [#7685].azdxignore for watch mode: Create a .azdxignore file in the project root (gitignore syntax) to exclude directories such as node_modules/ and dist/ from triggering unnecessary rebuilds during azd x watch. [#7697]
Preflight validationazd provision now warns before deploying when predicted resource names contain Azure reserved words (such as names with MICROSOFT, WINDOWS, or prefixed with LOGIN), with color-highlighted output. The check correctly skips Azure Resource Manager (ARM) allow-listed resource types (such as Private Link DNS zones, resource groups, and role assignments) that accept reserved names server-side. [#7746] [#7819]
Developer experienceazd update public preview: azd update no longer requires an alpha feature flag and displays a preview notice on first use. Read more in Stop juggling package managers, run azd update. [#7489]--non-interactive flag alias: --non-interactive is now a global alias for --no-prompt, and the AZD_NON_INTERACTIVE environment variable enables non-interactive mode. [#7392]--no-prompt failures: --no-prompt now consistently fails with a structured error when required input (subscription, location, or resource group) can’t be resolved automatically, enabling reliable non-interactive use in continuous integration and continuous deployment (CI/CD) pipelines and AI agents. [#7825]docker.network option: A new docker.network field in azure.yaml service configuration passes --network to docker build for services that require host networking (such as builds behind corporate proxies). [#7361]azd auth token output: azd auth token now prints the raw access token by default. Use --output json for structured output including expiration metadata. [#7384]azd pipeline config no longer prompts for parameters that are outputs of earlier provisioning layers, reducing unnecessary prompts in multi-layer deployments. [#7296]azd init -t <template> creates a new directoryRunning azd init -t <template> now creates a project directory named after the template (similar to git clone) instead of initializing in the current directory. Pass an optional [directory] positional argument to override the name, or pass . to restore the previous in-place behavior:
azd init -t <template> .The automatic slot-selection heuristics for App Service deployments are replaced with explicit slot targeting. Set AZD_DEPLOY_{SERVICE}_SLOT_NAME=production to deploy to the main app, or AZD_DEPLOY_{SERVICE}_SLOT_NAME=<name> for a specific slot.
The previous auto pick behavior (single slot present, no SLOT_NAME set, --no-prompt) and first-deploy push-to-all-slots behavior are removed. When slots are present and SLOT_NAME isn’t set, azd deploy prompts interactively or errors in non-interactive mode. [#7630]
Bugs fixedThis release includes several security-related fixes. Users are encouraged to upgrade (azd update).
azd update. The installer now refactors how MSI install script arguments are constructed for stable and daily channels, and rejects MSI packages that aren’t signed by the expected publisher. This closes a path where a tampered or substituted MSI could be silently installed during an in-place update on Windows. [#7298]azd and extension subprocesses. Because extension commands set DisableFlagParsing: true, cobra never parsed the -e/--environment flag, so the DI resolver fell back to the default environment and extensions could receive secrets or configuration from the wrong azd environment. The fix introduces a globalOptions parser that runs before cobra and is used consistently by both the DI resolver and extension invocation. The same change restores broken --debug, --cwd, and -e/--environment flag propagation to extension commands that regressed in an earlier revert. Validation of environment names is intentionally lenient so that extensions reusing -e for non-env-name values (such as URLs) continue to work. [#7314]os.Chdir call from Aspire server initialization. The previous implementation mutated the process-wide working directory in InitializeAsync, an ambient-authority pattern that could cause concurrency issues when other goroutines or concurrent operations relied on the working directory. rootPath was already passed explicitly to every consumer, so the call was unnecessary as well as unsafe. [#7362]AADSTS530084 token protection errors to display clear guidance and documentation links instead of an opaque failure message. [#7797]AADSTS70043 and AADSTS700082 errors; azd now returns guidance targeting the correct subscription tenant when a credential fails due to a stale refresh token. [#7578]AZURE_PRINCIPAL_ID resolution for guest and business-to-business users by resolving the principal identity in the subscription’s resource tenant, and prefer the ARM token oid claim over a Microsoft Graph call to avoid incorrect role assignments. [#7549]azd auth token is called with an unsupported --output format. [#7356]azd auth token being cancelled by the background update check when invoked as a subprocess by extension credential providers. Fast-exit commands now skip the update check entirely. [#7629]azure.yaml hook parsing failure when mixing single-hook (map) and multi-hook (list) formats in the same hooks: block. [#7618]../../hooks/script.ps1) failing with “hook script path escapes project root.” The containment boundary is now the project root instead of the service directory (regression in 1.23.15). [#7689]azure.yaml generating invalid environment variable names (such as SERVICE_API AND FRONTEND_IMAGE_NAME → SERVICE_API_AND_FRONTEND_IMAGE_NAME). [#7723]docker.path and docker.context in azure.yaml being resolved relative to the service directory instead of the project root when user-specified values are provided. [#7600]azure.yaml contains services, resources, or hooks with empty definitions. Reports all issues in a single actionable error message. [#7343]azd pipeline config --provider azdo failing when no agent queue named “Default” exists. azd now queries available queues, automatically selects when only one is present, and prompts the user to choose when multiple queues are available. [#7707]copilot.errorHandling.fix=allow) to automatically retry the failed command after applying a fix, instead of only applying the fix without retrying. [#7768]azure.yaml config validation errors as not fixable, and apply a 5-minute guard timeout to AI analysis requests. [#7555][A, [B, [C, [D) in the filter text of select and multi-select prompts when running azd in PowerShell. [#7642]azd update on Windows failing when PowerShell 7 and 5.1 are both installed. Reset PSModulePath before invoking the installer to prevent module path conflicts. [#7703]azd update error message when the installation is managed by an administrator, with guidance to suppress update notifications through AZD_SKIP_UPDATE_CHECK=1. [#7417]azd up and azd deploy performance with connection pooling, adaptive ARM poll frequency (5 seconds for deployments, 15 seconds for WhatIf/Validate), per-registry Azure Container Registry login caching, and Container App revision poll frequency (5 seconds). [#7600]azd update success message to a shorter, more actionable format. [#7591]copilot consent list and copilot consent revoke --action flag to display correct valid values (all, readonly) in shell completion suggestions. [#7588]azure.yaml, including dependency management and executor configuration.azd, covering AI-assisted project setup and error troubleshooting flows.azd workflows.Community-driven templates help you get started faster, solve real-world scenarios, and showcase best practices for deploying solutions with Azure Developer CLI.
The Azure Developer CLI template gallery continues to grow with exciting new contributions from the community. Thank you!
New to azd?If you’re new to the Azure Developer CLI, azd is an open-source command-line tool that accelerates the time it takes to get your application from local development environment to Azure. azd provides best practice, developer-friendly commands that map to key stages in your workflow, whether you’re working in the terminal, your editor or CI/CD.
The post Azure Developer CLI (azd) – April 2026 appeared first on Azure SDK Blog.
